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Crew Aiding and Automation: A System Concept for Terminal 
Area Operations, and Guidelines for Automation Design 


John P. Dwyer 

McDonnell Douglas Aerospace 
Advanced Transport Aircraft Development 

SUMMARY 


This research and development program comprised two sets of technical efforts: 
The development of a set of guidelines for the design of automated systems, with 
particular emphasis on automation design that takes advantage of contextual 
information; and the concept-level design of a crew aiding system — the Terminal 
Area Navigation Decision Aiding Mediator (T AND AM). This concept outlines a 
system capable of organizing navigation and communication information and 
assisting the crew in executing the operations required in descent and approach. 
This design concept exemplified the incorporation of the automation guidelines, 
and provided a design that was responsive to the requirements of the commercial 
transport mission. In service of this endeavor, problem definition activities were 
conducted that identified terminal area navigation and guidance as the focns for 
the ensuing conceptual design activity. The effort began with detailed 
requirements definition and operational familiarization exercises of direct 
relevance to the terminal area navigation problem. Both airborne and ground- 
based (ATC) elements of aircraft control were extensively researched. The 
products of these activities constituted the starting points for the design effort, in 
which the TANDAM system concept was specified, and the crew interface and 
associated systems were described. Additionally, three detailed descent and 
approach scenarios were devised in order to illustrate the principal functions of 
the TANDAM system concept in relation to the crew, the aircraft, and ATC. A 
proposed test plan for the evaluation of the TANDAM system was established. 

The guidelines were developed and refined based on reviews of relevant 
literature, and on experience gained in the design effort. 



INTRODUCTION 


BACKGROUND 

The development of modem transport aircraft continues to introduce new, 
powerful technologies to the domain of the National Airspace System. 
Advances in data input, analysis, and transfer, coupled with developments 
in information display, control, and management have provided the air 
transport crew with the potential for unprecedented operational 
capabilities. Current automated systems for information management, 

(i.e., systems that organize, filter, and provide other systems and the crew 
with vital information) have made possible dramatic improvements in ride 
quality, fuel bum, navigation, systems monitoring and diagnosis, and 
communications. Automation has also played heavily in the recent 
incorporation of time-critical safety systems such as the Traffic alert and 
Collision Avoidance System (TCAS) and reactive windshear technologies. 
In the near future, these advances in airborne automation will be 
accompanied by major changes in equipment and procedures for ground- 
based air traffic management. Next generation Air Traffic Control (ATC) 
will rely heavily on automation for assistance in aircraft spacing, flow 
rates, collision avoidance, complex approaches, handoffs, and air-ground 
communications— all designed to increase capacity and efficiency while 
maintaining or even increasing levels of air travel safety. 

These increased capabilities arrive at a time when they are sorely needed; 
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by some accounts, air transport passenger growth will more than double in 
the next two decades, and instrument controlled operations will be more 
than half again as frequent in terminal areas as they are at present 
(reviewed in ref. 1). However, according to researchers such as Wiener 
(ref. 2), the full benefits of these capabilities have yet to be realized. 

Sarter and Woods (ref. 3), for example, reported that pilots view certain 
Flight Management System functions as providing advanced capabilities at 
the price of increased crew workload, difficulty in anticipating all of the 
automation s actions, and the possible degradation in the crew's awareness 
of the aircraft's overall status and flight situation. 

These concerns arising from operational experience with the current 
generation of automation have prompted NASA and industry to re-evaluate 
the implementations of these advanced capabilities. Billings (ref. 4), in his 
review of cockpit automation, states the issue succinctly: 

It should be noted immediately that it is not clear whether this [issue 
regarding the capabilities of some current automation] is an inherent 
automation problem, or whether this is because we have not provided simple 
enough interfaces through which pilots interact with automation, (p. 17) 

One often mentioned concern about current automation is that designers 
have not gone far enough in accommodating and capitalizing on human 
cognitive and perceptual abilities. For example, in a comparison of 
operations in more and less automated cockpits, Wiener and his colleagues 
(ref. 5) observed that ostensively similar navigation tasks - either 
performed manually (in one aircraft) or by means of automation (in 
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another) — demonstrated differences in crew procedures that did not take 
full advantage of the crew’s ability to effectively manage workload. 

In an effort to galvanize the research and development community around 
such concerns, NASA has developed a major research thrust that expressly 
calls for the development of automated systems designed to fully capitalize 
on the capabilities of the human operator while still providing to that 
operator the rather substantial benefits realizable with automation. This 
philosophy of "human-centered" automation was identified as critical to the 
success of the next generation of automated systems in NASA s Aviation 
Safety/ Automation Program" (ref. 6). Wiener and Curry (ref. 7) and 
Billings (ref. 4) have articulated the major tenets of this philosophy in the 
form of design guidelines and recommendations. 

Flight deck automation design can clearly profit from adherence to all 
aspects of human-centered design, but several general issues are of 
particular importance: 

- Ensuring that the crew can readily understand, anticipate, and influence 
the actions of the automation; 

Ensuring that use of the automation does not detract from, but rather 
enhances the crew's continual situation awareness; 

- Ensuring that the automation optimizes crew workload, and that it operates 
in an error-resistant and error-tolerant fashion, without contributing to 
such dangerous conditions as complacency or unnoticed failures; 
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Ensuring that the automation interface facilitates crew involvement and 
awareness, and maintains crew prerogative by recognizing and 
supplementing the crew's understanding of mission objectives, current 
flight status, and probable future situational variables. 

A human-centered approach to automation presupposes that the human 
operator possesses many of the critical skills and knowledge required for 
safe, efficient flight; this approach therefore endorses the employment of 
human capabilities as vital to successful design. Researchers and the pilot 
community both point to such human assets as the ability to leam from 
experience, to make quick, decisive judgements in uncertain, time-critical 
situations, and to cope with unanticipated, perplexing problems-even when 
these problems have, perhaps, never been encountered before, or when 
they may suggest no one "correct” solution. It is perhaps no surprise, 
therefore, that the most sophisticated efforts in developing artificial 
intelligence and other "smart" automated systems focus on these same 
problem-solving and decision-making abilities. Thus, it is essential that 
advanced automated systems assist the transport crew in these high-level 
tasks, if these systems are to be considered genuinely human-centered. But 
to be able to perform such functions, automated systems must be able to 
monitor and assess several classes of mission-relevant variables: The 
rapidly changing situation of the aircraft at any given point in its route, the 
more strategic elements of the mission plan (and modifications by ATC and 
other external conditions), the crew's cognitive and physical states, and 
their anticipated needs and preferences. In these important respects. 
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human-centered automation must be adaptive to the flight situation, and 
responsive to crew and mission demands. 

PROBLEM 

Information flow in the modem transport cockpit continues to increase in 
quantity and variety; the need to effectively manage and use this 
information is rapidly outstripping the limited processing capabilities of the 
human crew in many operational arenas (ref. 2; ref. 3). This explosion of 
information (and its consequent critical need for effective control) can be 
seen in virtually all flight-critical functions. 


- Communication functions— these can range from Data Link functions to 
voice communications activities. 

- Flight and navigation functions— this area encompasses several classes of 
activities: those currently covered by the Flight Guidance System and 
the Flight Management System; those related to aspects of flight control 
optimization; and those involved with such time-critical event systems as 
the Ground Proximity Warning System (GPWS), the Traffic alert and 
Collision Avoidance System (TCAS), and windshear alerts. 

- Aircraft systems functions-these concern functions involved with 
electrical, hydraulic, fuel, and propulsion systems. Future applications 
include sophisticated component failure diagnostic capabilities associated 
with a broad range of onboard systems. 
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It is evident, then, that effective human interface systems, automation 
responsive to mission requirements, and other aspects of human-centered 
design will have to keep pace with the rapid development of flight deck 
automation if successful implementation is to result. And while pilots’ 
opinions of current-day automation are clearly positive, their concerns 
with some aspects of current implementation readily highlight areas for 
improvement. For example, studies by Wiener (ref. 2) and Billings (ref. 
4) have reported that crews characterize some instances of automation as: 

Sometimes confusing or opaque in their operation, and in the 
consequences of their actions; 

- Workload-intensive during already high-workload periods and 
workload-alleviating during already low-workload periods; 

Insidious with respect to error creation and propagation, and inadequate 
with respect to error detection and rectification; 

- Unresponsive or cumbersome with regard to on-line modifications 
necessitated by unplanned changes or unanticipated events; and 

- Poorly integrated with related onboard and/or ground-based systems. 

Researchers have characterized the crew's changing role in the modem, 
highly automated cockpit as moving from continuous hands-on control of 
the aircraft to managing its many sophisticated systems. While this is 
certainly true, the characterization does not sufficiently emphasize the 
important point that this new managerial role, if not executed prudently, 
carries with it the danger of removing the crew from their primary 
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responsibility— safely and efficiently transporting passengers and aircraft 
from Point A to Point B. In this important sense, the role of the crew has 
not changed and is not likely to change in the near future. The problem, 
then, is how to allow the crew to maintain involvement, prerogative, and 
awareness of mission functions while fully exploiting the capabilities of 
automated assistance to efficiently perform these essential duties. 


RESEARCH OBJECTIVES 

The principal goal of this research was to develop and demonstrate a 
concept for an automated system capable of fully exploiting situation- 
specific information in order to tailor and optimize its assistance to the 
aircrew. This use of situational cues (e.g., significant flight plan events, 
environmental conditions, aircraft state data, crew inputs, and ATC 
directives) to constrain and direct the automation s operation is herein 
referred to as employing "context-sensitive" automation. Based on analyses 
of accident and incident reports and other relevant operational data, 
descent- and approach-phase navigation and communication activities were 
identified as the functional domains to be incorporated in this conceptual 
design. At the onset, it was clear that this research was to embrace two 
related themes: A heavy reliance on human-centered design principles and 
guidelines, and the aforementioned incorporation of automation concepts 
capable of adapting to and utilizing operational, situational, and crew- 
initiated inputs. It was anticipated that the concept for the automated 
system would, where appropriate, incorporate or accommodate: 
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Mission/functional requirements and safety considerations; 

Situational conditions that could vary due to mission phase, specific 
events (planned and unplanned), pilot preference, etc.; 

Mental models, and other cognitive, perceptual, and operational 
characteristics of crew members. Included also in this concern were 
relevant crew emotional and physiological states. 

A supporting goal of this research was the delineation of improved 
integration and coordinated operation of the system concept with other 
airborne (e.g., Data Link) and ground-based systems. This goal was served 
by conducting research concerning the overall integration of the individual 
onboard systems at a crew system information management level. Among 
other duties, this overall mission/aircraft management function would be 
responsible for the timely coordination and high-level processing of all 
aircraft systems necessary for continual crew involvement and control. 


The second major goal of this program was to develop design guidelines 
suitable for assisting designers in their creation of automation. Particular 
emphasis was placed on developing guidelines for automation designed to 
exploit aspects of specific situational information. Significant efforts were 
made to ensure that these guidelines incorporated relevant issues raised in 
other existing design guidelines documents. 


9 



APPROACH 


OVERVIEW 

This research and development program comprised two technical efforts: (1) 
The development of a set of guidelines for the design of automated systems, 
with particular focus placed on automation that takes advantage of contextual 
information; and (2) the conceptual design of an automated system capable of 
assisting the crew in terminal area navigation and communication operations. 
The design effort would both exemplify the incorporation of the guidelines, 
and hopefully offer a point design demonstrating the superior value of an 
automated system responsive to the mission-driven requirements of the 
commercial transport environment. These two sets of technical activities are 
schematicized in Figure 1. As is depicted in the figure, identifying candidates 
for automation and conducting preliminary problem definition activities 
yielded the (aforementioned) candidate issue for the resulting design effort. 
These activities and a literature review also provided inputs to the generation 
of the design guidelines. The design effort began with detailed requirements 
definition, and operational familiarization activities of direct relevance to the 
terminal area navigation and communication problem. The products of these 
activities constituted the starting points for the design effort proper, in which 
the system concept was specified, and the crew interface and associated 
systems were described. A test plan for the evaluation of the system concept 
was then established. Guidelines for conducting design efforts with technical 
objectives similar to the present endeavor were documented. 
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FIGURE 1. TECHNICAL APPROACH 
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DESCRIPTION OF PROJECT ACTIVITIES 


Development of Design Guidelines 

Development of the design guidelines began with a review of two sets of 
technical literature! A sizable and varied set of papers addressing issues in 
automation development, and a small number of papers offering design 
guidelines, general suggestions, and organizational schemes relevant to 
automation design. From these readings, and from our experiences on the 
present design effort, a framework for the current guidelines was established. 
Detailed design guidelines (gleaned from this literature review and developed 
in the course of the current design effort) were then generated in response to 
this organization. These guidelines were subsequently reviewed and refined 
by McDonnell Douglas Corporation (MDC) crew station design personnel. 

Problem Definition for Design of an Automated System 

The first component of the design effort was a problem definition activity 
involving the analysis of incident and accident data, and the review of 
literature germane to operational problems and to automation issues generally. 
Incident and accident data were obtained from three sources: A data base 
maintained by MDC, anecdotal accounts and pilot interview responses 
reported in research papers (e.g., ref. 4), and a contractor-solicited Aviation 
Safety Reporting System analysis of FMS operation problems occurring 
during descents and approaches (ref. 8). Analysis of these data yielded a 
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fairly clear representation of the problems with current automated systems 
(principally the FMS), and a rough indication of what aspects of the mission 
(in terms of crew workload and situation awareness, phase of flight, aircraft 
configuration, and external conditions) "invited" their characteristic 
occurrence. This analysis also provided indirect guidance for recognizing 
potential design shortcomings, and for suggesting ways of preventing their 
incorporation into future systems. 

The literature review generally supported and amplified the aforementioned 
incident/accident findings, and also provided information as to the probable 
direction and scope of advanced automation technologies currently under 
development for inclusion in the National Airspace System. Airborne 
technologies mentioned included sophisticated data base systems, 4-D 
navigation capabilities, differential global positioning systems, and Data Link 
systems. Ground-based developments ranged from automated maintenance 
and diagnosis equipment to the Center/TRACON Automation System (CTAS) 
designed to control aircraft spacing in the terminal area. This information 
was invaluable since it helped define the sort of general automated 
environment that could reasonably be assumed to exist in the time frame when 
a system like the one under consideration might become operational. 
Moreover, a thorough understanding of these advanced technology concepts 
(in particular, CTAS) proved to be a strong driver in the determination of the 
present system concept s functional requirements, and an important constraint 
on the responsibilities this system would possess, share, or depend upon from 
other sources. Similarly, insights were gained regarding the possible 
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allocations of functions between the aircrew and the automation. In large 
part, these insights dictated the role of the automated system and the design 
philosophy adopted in this concept development effort. 

This problem definition activity concluded with the identification of the 
general operational domain to be served by the automated system - 
navigation, guidance, and supporting communications functions occurring in 
descents, approaches, and landings. 

Operational Familiarization 

Following this problem definition effort, a number of operational 
familiarization activities were pursued. Familiarization with relevant airborne 
systems and operations covered an extensive range of activities. The MD-1 l's 
Computer-Based Training (CBT) program offered operational information 
about all major guidance and control systems. CBT sessions on the MD-1 1 s 
Autoflight system (Autopilot, Autothrottles, etc.). Flight Management System 
(FMS), and associated displays and controls provided detailed procedural 
knowledge regarding these systems and their functioning. Extensive reviews 
of the MD-1 l’s various operational manuals complemented the CBT 
information. The MD-88's operational manual for its FMS was also studied in 
order to compare this earlier generation flight guidance and navigation 
automation with the MD-1 l's configuration. 
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Accompanying these efforts to become familiar with existing automated 
systems were reviews of a number of critical capabilities not yet in service (in 
their more fully capable versions). Airborne 4-D navigation (i.e., navigation 
including precise schedule constraints along the route) capabilities were 
reviewed for their obvious potential utility for advanced navigation 
management. Concepts for Data Link systems — including interface issues 
such as display content and format, and air-ground interactive requirements ~ 
were evaluated so as to ascertain the probable operational advantages and 
limitations they would present for the automated system under consideration 
in this research effort. Familiarization with airborne systems also included a 
review of the sophisticated capabilities and operations envisioned for next- 
generation commercial transports such as the Enhanced Cockpit (EC) concept 
for the MD-90 aircraft. 

Substantial familiarization with the relevant ground-based systems was seen as 
essential to the ultimate viability of the automated system design concept under 
development in the present research effort. To this end, significant effort was 
expended studying the procedures of terminal area air traffic controllers and 
their associated reasoning and decision making. Familiarization ac ’ cities 
included studying ATC-related research reports, monitoring ATC-a.rcraft 
clearance sequences, observing TRACON controllers, and con « in, > 
extensive interviews with a number of these controllers. 

In addition to surveying current ATC procedures and functions, a concerted 
effort was made to become familiar with relevant aspects of ATC's next 
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generation of automation aids and computational capabilities. Chief among 
these (at least with respect to the current design effort) is NASA's 
Center/TRACON Automation System (CTAS) which will function to assist 
controllers in scheduling and metering aircraft as they enter the terminal 
control area. The means by which this control of aircraft order and spacing is 
accomplished -- complex clearances optimized to reduce overall delays - had 
an important impact on the proposed operation (and capability) of the system 
concept developed in the present research effort. 

Requirements Definition and Technical Assessment 


Consideration of the automation issues identified in the previously discussed 
literature review, and familiarization with airborne and ground-based 
technologies in the National Airspace System, directed the present research 
effort to develop a concept for a crew aiding system - the Terminal Area 
Navigation Decision Aiding Mediator (TANDAM) - that would assist the 
crew in executing next-generation navigation, guidance and communication 
functions to be required in Descent and Approach operations. To this end, 
functional requirements for the TANDAM system were derived, and these, in 
turn, were translated into design requirements. Functional capabilities of the 
TANDAM system concept were supported by a thorough incorporation of 
human-centered design principles, and by considering the employment of 
flight-context triggered cuing mechanisms to enable the automation to be 
responsive to situational changes throughout the mission. The TANDAM 
system would conduct such navigation and guidance activities as presenting 
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ATC clearances to the crew, assisting in the evaluation and possible 
negotiation of these clearances, preparing probable alternate routes subsequent 
to clearances, readying the flight deck for anticipated changes (e.g., runway 
step-over maneuvers), and facilitating the down-linking of context-specific 
information (e.g., weather at altitude, estimated waypoint arrival times). 

These capabilities were demonstrated in operationally representative Descent 
and Approach scenarios. In these scenarios, critical aspects of the TANDAM 
system's performance were shown in the temporally sequenced context of 
probable future operational procedures involving the crew and ATC 
(principally via CTAS), and utilizing an advanced, 4-D capable navigation and 
guidance system, and Data Link. The scenarios were designed to be relatively 
realistic in terms of hardware and software capabilities, operational 
requirements, situational influences, and crew and ATC workload. Three 
scenarios were generated: A descent and approach into Los Angeles 
International Airport (LAX) under CTAS governance and using Data Link, a 
descent and approach into John Wayne Airport (SNA) without the benefit of 
CTAS or Data Link, and an approach into LAX (with CTAS and Data Link) 
focusing on preparations for a possible change in runway assignments. 

Conceptual Design of the TANDAM system 

The functional organization, and detailed capabilities of the TANDAM system 
were articulated to define the system concept, and to better delineate the 
system s role as a navigation and guidance assistant. In support of this goal, 
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critical interface elements (e.g., the Flight Mode Control Panel, Navigation 
Display formats), procedures regarding 4-D clearance negotiations, and 
automation/crew interactions were described. Schematics of some significant 
operational capabilities were provided in order to suggest possible directions 
for the eventual structure of the TANDAM system s functional architecture. 
Lastly, the TANDAM system was portrayed in its functional relationship with 
other aircraft systems in order to demonstrate its anticipated integration and 
coordination with these systems. 

Products 


A number of significant design products were developed in the course of this 
research project, and are presented in this report. First, in consideration of 
certain critical assumptions and philosophy issues, the utility of automation 
design guidelines was addressed. These positions made explicit, guidelines for 
the design of automated systems were documented, and have been placed m an 
appendix to the main body of the report (due to their substantial length). The 
report also contains the detailed description of the TANDAM system concept, 
and the three descent and approach scenarios instantiating its operation and 
functional interaction with the aircraft, crew, and ATC. These capabilities, 
initially excerpted from the descent and approach scenarios, were elaborated 
upon to further explicate significant aspects of the system s potential 
operational utility. A test plan to evaluate a more complete and refined 
version of the TANDAM system is also provided. This plan describes the 
proposed scope and method of evaluation, as well as the test s general content. 
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The test was designed to evaluate several relevant factors: Operational utility; 
ease and accuracy of crew usage; depth and accuracy of system functioning; 
and potential for enhanced safety and economic advantage. 
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RESULTS 


ISSUES REGARDING DESIGN PHILOSOPHY AND THE 
DEVELOPMENT OF GUIDELINES 

The assumptions and philosophical positions adopted in the development of the 
automation guidelines are now discussed in some detail. This underlying 
philosophy was articulated so as to make explicit the design principles embodied 
in the guidelines, and to thereby explain the reasons for choices made in their 
construction. These assumptions address several areas of design: Software and 
hardware capabilities; automation control, operating logics, and computational 
techniques; and the role of the automation and the operator in the control of the 
mission function(s) being supported. In (at least) these important respects, the 
assumptions designers make can clearly have significant and often critical 
influence over the capabilities and appropriateness of the automated systems 
developed for future commercial flight decks. The guidelines themselves are 
presented in the appendix to this document. 

Introductory Comments 

Recommendations and guidelines for the effective design of automated systems 
share a number of important characteristics with other design guidelines. For 
example, since the human operator often interacts with the automated system, 
guidelines regarding the design of an interface are typically relevant. And, since 
the automated systems are specialized software and/or hardware systems residing 
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in the overall avionics system, guidelines for the design of such technologies are, 
of course, pertinent. What makes automation design unique, however, is the need 
to establish guidelines advising designers about translating operational and 
functional requirements into routines for gathering and interpreting data, 
applying rules, etc., and subsequently executing advisories and/or commands to 
the aircraft and crew. In this sense, design guidelines for automation must 
consider both the system's states and the crew's strategic awareness and 
understanding of those states. 


Thus, the desire to provide specific, concrete guidelines is often, of necessity, 
replaced with the goal of developing guidelines that keep the designer responsive 
to the general intent of the design requirement. For example, how a particular 
system is programmed may be irrelevant from a design point of view; however, 
how it acts as a result of that programming (i.e., how it obtains information, 
processes it, makes interpretations, and informs its users) is of central concern to 
the designer. 

It is essential to keep in mind that the designer of an automated system is (or at 
least should be) driven by one overriding concern: The satisfaction of mission 
and functional requirements. Moreover, the means by which this automated 
system satisfies these requirements must follow two interrelated tenets: The 
designed system must be able to effectively accomplish (or support) the execution 
of its identified technical tasks (e.g., ensuring that 4-D calculations to a fix are 
accurate and timely), and it must be able to accomplish these tasks in ways that 
involve, inform, and assist the crew without also resulting in undue levels of 
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workload, and while still ensuring an optimal level of situational awareness. 
Moreover, this second tenet, often referred to as human-centered design, 
demands that this inclusion of the human operator go well beyond mere 
accommodation of his or her presence. Human-centered design endeavors to 
develop technologies that take advantage of human cognitive and perceptual 
strengths and preferences, and that help compensate for human limitations. These 
guidelines for the design of automated systems must, therefore, direct the 
designer of advanced commercial flight decks to remain cognizant of human 
skills and their possible utility in satisfying the mission and functional 
requirements. 

Assumptions and Design Philosophy 

In any design effort, assumptions must be made regarding mission requirements, 
relative level of functional advancement over current flight deck capabilities, 
software and hardware capabilities, and extent of the system s impact on the 
integrity of other cockpit systems, and on the crew's procedures. These 
assumptions in large part govern the designer's thinking in the design process, 
and greatly constrain the design philosophy adopted — the designer does well to 
make explicit the assumptions of the design goal and the consequent design 
philosophy being followed. Determination of these assumptions could come from 
any number of pragmatic, technical, or theoretical considerations. In human- 
centered design, assumptions must be the products of mission requirements, 
human information processing capabilities, and constraints emergent from other 
relevant systems, procedures, and the like. 
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In any effort to design an automated system for an advanced flight deck, several 
assumptions must be made if a coherent, principled design is to be developed. 
Chief among these are assumptions regarding the following general design 
parameters. 

Software and hardware system capabilities. In the case of the present 
design effort, several current avionics technologies (e.g., the Flight Guidance 
System) will be assumed to exist in advanced forms. Some of the required 
technologies would possess substantially enhanced capabilities (e.g., the FMS will 
need to be able to rapidly load and customize alternate flight plans, approach 
plates, etc.), and certain of the technologies not yet in service (e.g., onboard 4-D 
navigation, CTAS) would be posited to be operational in the time frame 
envisioned for the automated system’s incorporation into the commercial 
transport fleet. 

The types of systems controls, operating logics, and associated 
computational schemes. In the case of the present effort, the design 
philosophy chosen was to be as conservative as possible (i.e., deterministic, rule- 
based) in the programming techniques that would be called for to support the 
automated system concept. In the case of this design effort, this decision was 
motivated by the kinds of operational capabilities revealed in the analysis of 
mission requirements and further articulated in the development of the scenarios 
(e.g., facilitating the negotiation of a 4-D descent clearance). In the problems 
identified for terminal area navigation operations, standard computational 
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techniques (that were fast and able to deal with large bodies of data) would 
probably be able to accomplish the large majority of mission functions called out 
in the scenarios. In the design of automated systems for more advanced flight 
deck applications, programming approaches such as neural network technologies 
or various non-deterministic (probabilistic) computational techniques might be 
required. 

Determination of the extent of automaticity versus extent of human 
involvement. One decision crucial to the choice of design philosophy is 
determining the degree to which the automation will function autonomously, 
versus the degree to which dependence on human monitoring and intervention 
will be required. This issue of extent of automaticity is critical since the 
consequences of a poorly thought out philosophy in this regard can result, at one 
extreme, in ineffectual (minimal) automation and, at the other, in completely 
opaque and surprising (maximal) automated control. Unfortunately, this decision 
is too often made on the basis of any number of peripheral criteria - technical 
feasibility, for example, or even simple expedience. From a human-centered 
design perspective, only the potential for reduced workload, the expectation of 
maintained or increased situational awareness, and the ability to capitalize on 
mission-enhancing options should be determinants of the applicability and extent 

of automaticity. 


However, determining the appropriate extent of automated functioning is 
potentially complicated by other tenets of human-centered design. Consider, for 
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example, two of Charles Billings' (ref. 4) general principles for human-centered 
automation: 

"To command effectively, the human operator must be involved, (p. 13)" 

"To be involved, the human operator must be informed, (p. 13)" 

Taking these principles at face value, one could reason that the more involved 
(and, by implication, informed) the human operator, the more in command that 
operator would be. But, since one of the typical motivations for deciding to 
automate is to unburden the operator from having to be cognizant of all aspects 
of a function, - that is, purposefully rendering the operator Jess informed about 
every detail of the function's execution - automating could easily be seen as 
lessening informativeness and involvement, and therefore being opposed to 
Billings' design principles. 


The resolution to this apparent dilemma, of course, lies in what the human 
operator is informed about. Billings is certainly not recommending that an 
automated system should tell the operator about every detail of that system's 
processing. Rather, he is recommending that the automated system (and any 
context-sensitive mechanisms used to support it) be crafted such that precisely and 
only the relevant calculations, events, states, etc., be interpreted for, and reported 
to, the crew. 

To re-couch the issue then, it is perhaps more accurate to say that the appropriate 
degree of automaticity is determined by the designer's success in first identifying 
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the essential operational information required by the operator (for situation 
awareness), and then effectively presenting that information to the operator in the 
course of the system's execution of the automated function. In this regard, then, 
the designer cannot be free to make the arbitrary decision to specify more or less 
automated functioning - done correctly, such decisions can only result from an 
understanding of human information processing requirements, and the missions 

purpose. 

In summary, it is evident that the determination of automation requirements 
should be based on a thorough understanding of mission requirements, 
operational constraints, and human capabilities and limitations. This 
understanding is essential since it is on its basis that the designer must determine 
what functions and activities, in what contexts, should be accomplished or assisted 
by an automated system. This understanding must be both comprehensive (in 
terms of mission goals) and procedural (in terms of specific crew and system 
decisions and activities) so as to provide the designer with both strategic and 
tactical goals for the system design. The understanding of the mission objectives 
and operational context - whether learned from flight phase, environmental 
factors, or pilot state — provide the cuing mechanisms for enlisting the assistance 
of the automated system, and for determining what data must be evaluated and 
what decisions and actions must be considered. 
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PROBLEM IDENTIFICATION AND OPERATIONAL 
CONSIDERATIONS 

Determination of the operational problem being addressed in the current design 
effort was based on an evaluation of automation use in current "glass cockpit" 
aircraft. This evaluation first considered summary statistic and anecdotal reports 
of incidents and accidents relevant to cockpit automation. Also reviewed were 
compilations of pilot-solicited comments regarding the operation and 
understanding of automated systems. Additionally, this evaluation studied 
experimental investigations demonstrating characteristic procedural errors, non- 
optimal uses of the airborne systems, and problems with mode awareness and 
consequences related to flight deck automation. 

From this evaluation, evidence converged on a number of interrelated factors that 
have all contributed to the identification of the functional problems addressed in 
the present TANDAM system design concept. A summary of this evidence, and 
an explanation of its consequence for this research effort, are now provided. 

Characterizing Problems with Cockpit Automation 


As was indicated above, reports of incidents and accidents were evaluated for 
their relevance to the identification of possible problems with current automation. 
Two types of reports were available for analysis: Incidents and accidents 
obligatorily reported to the FAA (and subsequently recorded in aircraft safety 
data bases), and pilot accounts elicited in various interview settings. 
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The present study’s analysis of incident and accident data was accomplished in 
two phases. First, an inspection of Douglas Aircraft Company s Commercial Jet 
Transport Safety Statistics; 1991" (ref. 9) document was performed in order to 
establish general statistical trends regarding aircraft safety mishaps, etc. This 
review of aircraft safety data revealed a number of relevant statistical patterns. 

For example, of the approximately 1285 serious accidents (with aircraft damage 
sustained) observed between 1958 and 1991, 736 (57%) occurred during 
approach and landing, even though only about 15% of an average flights time is 
spent in these phases. The flight phase containing the next most frequent accident 
occurrence, takeoff (typically comprising about 1% of total flight tune) 
accounted for some 18% (237) of the total events, and exhibited over twice the 
accident frequency observed for any of the remaining flight phases. For the 
purposes of the current design effort, it is significant to note that aircraft safety 
data also showed that the majority of accidents that related to problems with 
control activities involved crew-induced mishaps. Moreover, of accidents clearly 
involving crew behaviors, the captain’s actions have been at least partially 
responsible in 657 (80%) of the 817 recorded cases. Of these captain-involved 
accidents, less than adequate executive (i.e., command) actions (40%) and 
judgements (21%), and failure to follow proper procedures (11%) were cited in 
the clear majority of cases. Other reasons implicated in captain-involved 
accidents included less than adequate awareness (6%), failure to monitor 
instruments (5%), less than adequate preparations (4%), failure to take immediate 
action (3%), and failure to use proper safety procedures (3%). 
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After this general pass through reported safety data, a search of McDonnell 
Douglas Aerospace s aircraft safety data base was conducted using a small 
number of selection criteria: Events were selected that were reported between 
1983 and 1992 mclusive, that had occurred in any phase of flight, and that had 
appeared to have involved (or at least implicated) some onboard automated 
system. This search yielded 64 events. Subsequent inspection of these events 
yielded 32 that were reliably classifiable in terms of phase of flight, and probable 
type of automated flight function involved and phase of flight. As can be seen in 
Figure 2, the overwhelming majority of these events occurred in the Approach 
and Landing phases and involved navigation and guidance functions. Of this 
group, the most frequent problems concerned various nonprecision approaches 
and non-optimal environmental conditions, and thus tended to involve the 

operation of autoflight systems, and navaid and tracking systems employed in 
final approach segments. 


A selected compilation of aircraft events recounted by Billings (ref. 4), identifies 
several critical examples of automation-related problems. Classification of these 
events, in terms of phase of flight and type of function, is shown in Figure 2. In 
Billings’ sample (not intended to be statistically representative), automation 
problems are noted in every phase of flight, and are most prevalent in Systems 
functions during Takeoff (as shown in Figure 2). 

Accounts of automation difficulties elicited from pilots are available in a number 
of studies (e.g., ref. 10). Some studies by Wiener and his colleagues (ref. 2; ref. 
5) are among the best of these accounts and are therefore used in this evaluation. 
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FIGURE 2. SUMMARY OF REPORTS OF PILOT ERRORS, INCIDENTS, AND 
ACCIDENTS AS A FUNCTION OF PHASE OF FLIGHT AND FUNCTIONAL DOMAIN 
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In these investigations, line pilots described experiences in which they 
encountered difficulties or made mistakes in their operations of automated 
systems such as the FMS and the Autoflight System. These elicited comments, 
again sorted in terms of flight phase and type of function, are presented in Figure 
2. This classification of reports indicates that pilots were most aware of 
navigation and guidance difficulties, followed by problems related to aircraft 
systems operations. And, as would be assumed, navigation and guidance 
problems were most prevalent subsequent to takeoff activities. 

To summarize thus far, a few significant patterns clearly recur in the foregoing 
studies and analyses. Firstly, while problems with present-day automation are 
possible in every phase of flight, their prevalence in later phases, and, in 
particular. Descent, Approach, and Landing, constitutes a significant portion (if 
not the majority) of all automation-related accidents, incidents, and operational 
difficulties. Secondly, the largest segment of these automation problems directly 
impacts navigation and guidance functions, and therefore tends to involve use of 
the FMS, the Autoflight System, and navaid tracking systems. And, while these 
analyses of the available data are admittedly imprecise and incomplete, they do 
unambiguously indict significant aspects of current automation, and strongly 
demonstrate the need for improved capability in future navigation and guidance 
automation. 
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Some Analyses of FMS-Related Difficulties 


This discussion of automation-related problems has now been narrowed to 
concentrate on difficulties with the management of navigation and guidance 
occurring during descents, approaches, and landings. To more precisely identify 
these FMS-involved difficulties, two (of the many available) representative 
studies are now considered. 

A survey of line pilots 

With an expressly exclusive focus on navigation functions, Sarter and Woods 
(ref. 3) surveyed 135 Boeing 737-300 pilots about their experiences operating 
that aircraft’s FMS. In their analysis, these researchers identified several specific 
FMS-related "surprises" — unforeseen or seemingly inexplicable behaviors of the 
FMS -- that were potentially problematic for effective planning and execution of 
navigation activities. These "surprises," along with the frequencies with which 
they were volunteered (pp. 15-19), are summarized here: 

- Problems related to the use of the FMS's Vertical Navigation Modes were 
common: 

- Pilots reported difficulties in understanding the logic of calculations 
related to vertical maneuvers, and were therefore often unable to 
accurately predict how and when such maneuvers would be initiated, 
maintained (or modified), and concluded. (38 reports) 


32 


Pilots reported difficulties in understanding the consequences (for the 
FMS plan) of interrupting an FMS-initiated vertical maneuver with a 
change executed on the Flight Mode Control Panel. (1 1 reports) 

- Pilots reported a general lack of understanding for how the FMS’s 
Vertical Navigation Speed Descent mode operates, including how targets, 
restrictions, and general maneuver calculation logics work. (8 reports) 

- Pilots reported substantial difficulties disengaging the Approach mode 
when required. (6 reports) 

Problems involving data entry were frequently cited, including problems 
arising from inadequate feedback after erroneous entries. (54 reports) 

Pilots indicated problems understanding and predicting FMS-initiated (so 
called "uncommanded") changes between flight modes. The most common 
situation mentioned was the FMS's reversion from Vertical Speed mode to 
Level Change mode when airspeed deviated from a critical range. (28 
reports) 

Not surprisingly, pilots volunteered that they lacked adequate understanding 
of infrequently used FMS features. (14 reports) 
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- Some pilots commented that pitch commands indicated with the PFD s flight 
director did not always appear appropriate to the maneuver being executed, 
and therefore lessened their confidence in the FMS logic. (11 reports) 

- Some pilots reported being confused about what the currently active target 
values are, owing largely to a lack of understanding of how the Autoflight 
System and the FMS were coordinating in a given flight regime (i.e., were 
the FMCP or the FMS settings active). (10 reports) 

- Several pilots expressed frustration with the relatively large - and in their 
opinions, excessive - number of ways to achieve various navigation and 
guidance functions. (10 reports) 

- Several pilots expressed frustration and concern about having to repeatedly 
enter the same data into different FMS pages. These pilots would have 
preferred that such data entry was done only once, and was then 
automatically copied to other relevant pages. (9 reports) 

- A few pilots admitted that they lacked a clear understanding of which 
subsystems of the FMS would remain operational in the event of failures of 
other components of the FMS. (3 reports) 
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Aviation Safety Reporting System findings 

In an effort to obtain a sample that was more representative of all FMSs currently 
in service, a NASA Aviation Safety Reporting System search was solicited on 
FMS-related incidents. The documentation of this search, "Last Minute FMS 
Reprogramming Changes" (ref. 8), presented pilot reports of FMS-involved 
incidents occurring in Climb, Cruise, Descent, and Approach phases (since the 
previously reported statistical data indicated that these flight phases yielded the 
majority of potentially significant problems with FMS functioning). The search 
of 38051 reports filed since the beginning of 1986 yielded 76 incidents, of which 
53 clearly implicated nominal operation of the FMS and/or the Flight Guidance 
System (FGS). Except for 2 incidents reported in Climb (1 FGS error, and 1 
FMS error), all occurred in Descent (39 FMS-, and 5 FGS- involved) and 

Approach (6 FMS-, and 1 FGS-involved). Figure 3 presents a summary of the 
reports for Descent and Approach phases. 

Of the FMS-involved incidents reported in Descent, the most numerous, 28, were 
caused by programming errors that lead to failures to attain assigned altitudes. In 
21 of these incidents, the aircraft's altitude was above the ATC directive, and in 
the remaining 7, it was below the assigned altitude. As is evident in Figure 3, the 
high altitude violations were fairly evenly split between incidents due to late 
initiations of FMS programming (10), and those in which the root causes were 
not adequately specified (11), suggesting that the late initiation count may well be 
underestimated in these reports. The 5 FGS-related incidents observed in 
Descents involved errors or misinterpretations of guidance parameter settings and 
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selections. Two of these were reported to have resulted in altitude busts; one in 
which the executed altitude was above the ATC assignment, and one in which it 
was below. 

Incidents reported for Approach were substantially fewer in frequency: 6 
involved FMS usage, and 1 involved the FGS. All of the FMS-related events 
involved programming errors, with 2 resulting from slow or late initiation of the 
programming sequence, and 4 resulting from input errors. In the single FGS- 
related Approach incident, the aircraft failed to descend when required by ATC. 

It is significant to report that confusions about the functional integration of the 
FMS and FGS were directly implicated in a small number of the aforementioned 
incidents (5), and appeared to be involved in several others as well. Pilots 
reported confusions about FMS or FGS control of flight modes and parameter 
settings, and about determining the "best" way to execute maneuvers required by 
ATC clearances. Similarly, 5 cases were reported in which pilots caused 
procedural errors, reportedly because focus on the FMS distracted them from 
adequately attending to immediate flight control and monitoring activities. 


Operating in the Future National Airspace 

The next generation of automation-assisted aircraft will operate in a National 
Airspace traffic control system that will itself be highly automated, and will 
provide greatly increased aircraft through-put and scheduling flexibility. 
Because of this, the determination of requirements for the automated system 
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under study in this research effort must be accomplished with due consideration 
given to this anticipated ATC environment. To this end, a brief description is 
now given of the ground-based ATC system that is assumed to be in place when 
the TANDAM system would be implemented in commercial transports. 
Specifically, air traffic control in the near future will be substantially aided by a 
highly integrated network of automated systems designed to help manage the 
control of arrival traffic. This network, the Center/TRACON Automation 
System (CTAS), will plan aircraft arrival schedules, and will determine optimal 
aircraft speeds, descents, and routes for the controller to use in managing precise 
sequencing and spacing functions (ref. 11; ref. 12). CTAS renders this assistance 
to the controller in the form of clearance advisories and graphically portrayed 
situational information. CTAS performs these functions by means of three 
interdependent modules: The Traffic Management Advisor (TMA), the Descent 
Advisor (DA), and the Final Approach Spacing Tool (FAST). 

Landing times (optimized to accommodate incoming aircraft) are calculated by 
the TMA in order to develop a continually updated landing schedule that 
minimizes delays for the great majority of incoming traffic. The TMA also 
ensures that the scheduling scheme that is generated minimizes the possibility of 
traffic conflicts by optimizing inter-aircraft spacing. 

The DA enables controllers to effectively command the maneuvers necessary to 
follow the TMA’s schedule by providing air speed and vertical speed profiles, 
and descent and turn advisories, all adhering to 4-D navigational constraints. 
Aircraft spacing is maintained first by speed-related commands, and when 
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necessary, by route-change commands as well. Additionally, the DA identifies 
down-route traffic conflicts, thereby enabling CTAS to issue resolution advisories 
well beyond the range of individual aircraft TCAS units. 

FAST, operating in the later stages of aircraft approaches, performs scheduling 
optimization and 4-D maneuver calculations essentially similar to those used in 
the TMA and DA, except that they are customized for fine-tuned control during 
final approach. FAST is also capable of assisting controllers with pop-ups and 
aircraft re-entering the pattern after a missed approach. 

With the assumption that clearances for descents and approaches will be largely 
governed by CTAS, an airborne navigation and guidance system appears to 
require substantial assistance from an onboard system designed to take advantage 
of situational variables and to work in accord with CTAS. This anticipated 
requirement is underscored by recent research by Williams and Green (ref. 13) 
in which effective compliance with CTAS-class 4-D clearances was demonstrated 
when a 4-D capable FMS and Data Link system were used. And Waller's Data 
Link simulation work exploring clearance receipt and execution (ref. 14) clearly 
suggested significant improvements in time to compliance when the Data Link 
system was capable of routing (accepted) clearance parameters to relevant 
navigation and guidance systems. The development of a concept (i.e., TANDAM) 
for such a system is therefore the objective of the present research effort. The 
description of this system concept - along with a number of flight scenarios 

employed to depict its major functional roles - is presented in the following 
sections of this report. 
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DESIGN CONCEPT FOR THE TANDAM SYSTEM 


The system concept developed in this research effort was designed to provide 
context-sensitive decision aiding (and other assistance) for crew activities in 
Descent and Approach flight phases. More specifically, the TANDAM system 
was designed to assist in 4-D navigation and guidance functions, and in the 
clearance negotiations often integral to these functions. The TANDAM system's 
functional organization, and its varied capabilities are now described. 

Description of the TANDAM System and Related Components 

To effectively execute its functions, the TANDAM system will rely heavily on the 
capabilities of a number of airborne and ground-based systems. Figure 4 
presents a schematic of these systems and their relationships with the TANDAM 
system and the aircraft. As can be seen in the figure, the TANDAM system 
interacts with airborne sensors, digital (and, to some extent, voice) 
communications systems, and an advanced flight management system. Crew 
interaction with the automation occurs on an advanced suite of controls and 
displays, specialized to accommodate the TANDAM system’s functions. (The 
TANDAM system's operation is depicted in detail in three flight scenarios 
presented later in this report.) 

Sensors and other onboard systems provide the FMS and the TANDAM system 
with continuously updated data on environmental conditions, aircraft 
performance, and configuration characteristics. They are also responsible for 
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CREW INTERFACE SYSTEM 




FIGURE 4. RELATIONSHIP OF THE TANDAU SYSTEM TO 
MAJOR AIRCRAFT FUNCTIONS AND THE CREW INTERFACE 
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providing aircraft position, altitude, and attitude information. As Figure 4 
indicates, the onboard systems may include advanced versions of air data systems, 
INS/IRS and differential GPS, Navaid receivers (for VORs, DMEs, ILS, etc.), 
weather radar, and TCAS. 

The communication systems, relying principally on an advanced Data Link 
system (e.g., satcom), send information to the FMS, and directly to the 
T AND AM system and the crew. These systems of course also downlink data to 
ATC and to the company. The most important (and typically the most 
demanding) information handled by these systems concerns complex 4-D 
clearances and their negotiations. Because of the interaction-intensive nature of 
these negotiations, no appreciable delays in transmission times will be tolerated 
(thus, for example, Mode S will not be adequate for these negotiations). 

The FMS and its associated data base conduct all navigation and guidance 
calculations, including 4-D estimations. Within the 4-D navigation capability, the 
FMS contains a module specialized for the calculation of vertical maneuvers. 

This 4-D navigation capability is able to continually re-calculate 4-D waypoint 
ETAs, deviations from on-time positions, and compensatory control inputs for 
maintaining or regaining these on-time positions. With the assistance of the 
TANDAM system, the FMS is able to continually modify its flight plan in 
reaction to onboard system, ATC, and other situational inputs. Computational 
speed, data base access, and storage (buffering) of data and of alternate 
calculations (of maneuvers, speeds, or whole route segments) will far exceed 
current FMS capabilities in terms of both capacity and sophistication. The flight 
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plan data base (including information on all relevant airways, departures, and 
approaches) will need to store detailed flight segment information such as altitude 
and other airspace restrictions, and uplinked information regarding current 
environmental and traffic conditions. Associated with significant mission events 
(e.g., obtaining ATIS information, or initiating a descent) will be data base 
elements that cue the TANDAM system to prepare various procedures designed 
to facilitate performance in these events (see the mission scenarios for examples). 
Also included in the data base will be tags for mission events typified as being 
high in workload and/or low in situation awareness. Again, these events will 
signal the TANDAM system to prepare assistance routines for use by the crew. 

In addition to facilitating clearance negotiations, these assistance procedures will 
include offering to take over selected crew tasks, apprising the crew about 
upcoming events, making recommendations or suggestions regarding these events 
(including recommending task rescheduling for workload management), 
informing the crew about significant consequences of current or proposed 
actions, and executing crew-selected commands. 

The TANDAM system will interact directly with the crew by means of a 
functionally integrated system of annunciators, displays, and controls. In this 
regard, the initial design position, therefore, was to use a modem "glass" cockpit 
configuration (an MD- 11 -class crew station) as the baseline, adding capabilities as 
design requirements dictated. As is evident from the preceding discussion, 
several necessary advanced capabilities have indeed been identified and all, to 
differing degrees, have had consequences for the crew interface. Those that have 
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constituted significant deviations from the MD-ll's controls and displays are 
presented in Figure 5 and will now be described. 


The Flight Mode Control Panel (FMCP) will generally resemble existing 
advanced FMCPs in both appearance and function (see Figure 6). However, one 
significant addition to this panel will be an 'Arrival Tune control that is 
designed to permit the input of fix arrival-time commands (in a manner 
analogous to heading and speed control arrangements). As such, the Arrival 
Time control will allow "time-at-fix" assignment, and will operate in pre-select 
and select modes. Time will be able to be set in either of two ways, in minutes 
and seconds from the present time, or in standard time coordinates. Additionally, 
the setting of a time will affect the planned flight path shown on the navigation 
display. The display will show the 4-D fix information, or will indicate that the 
time-at-fix could not be made. In the latter case, the display will indicate how 
late the aircraft would be, or where the aircraft would be at the proposed time 
setting. As with other FMCP entries, the consequent effects on speed and vertical 
rate will be displayed. A second element of the FMCP will be the incorporation 
of a pre-select feature for the vertical speed control. This feature was added to 
the FMCP to improve the crew's ability to prepare, inspect, and precisely execute 
4-D maneuvers. 


The last significant interface feature incorporated in the FMCP - the highly 
integrated functional relationship between the FMCP and the FMS — ensures that 
inputs to the FMCP will not inevitably cause problematic disengagements or 
discontinuities in the overall FMS governance of the flight plan. This advanced 
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FIGURE 5. MAIN INSTRUMENT PANELS FOR BASELINE 
COCKPIT, EMPHASIZING CONTROL AND DISPLAY 
SYSTEMS INTERFACING WITH THE TANDAM SYSTEM 
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FIGURE 6. 4-D GUIDANCE-CAPABLE FLIGHT MODE 

CONTROL PANEL 
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FMCP-FMS concept will be able to logically edit and modify an existing flight 
plan by simply entering new inputs in the FMCP (as well as in the FMS of 
course). In addition, the FMS MCDU's scratch pad can be used during FMCP 
editing to enter waypoints, etc., that are not in the current flight plan (and thus 
not accessible via the FMCP's scroll key). And a cursor pad device located on the 
FMCP can be used (in either FMCP or FMS modes) to quickly designate or 
create waypoints, etc., on the NAV display, and in the flight plan. FMS routines 
will be able to re-optimize the flight plan for the newly added modifications, 
especially with regard to the rather precise tolerances required of the 4-D flight 
path management posited for the TANDAM system's cockpit. 

The crew will be able to conduct flight path planning and editing on of the FMS 
using control features analogous to those outlined for the FMCP. The FMS will 
possess a real-time 4-D navigation capability that is fully editable, produces "hot" 
updates to all calculations, and can calculate running solutions (i.e., solutions that 
are automatically updated as input parameters change) to upcoming 4-D 
maneuvers. Moreover, all such calculations will be able to compensate for 
situation-specific variations (e.g., wind speed, direction shifts). And, information 
regarding such compensatory strategies will be readily accessible to the crew. 
Additionally, all course and time deviations resulting in scheduling violations 
(i.e., not able to be compensated for by the 4-D FMS) will be clearly indicated to 
the crew, along with any suggested replans, etc., to be considered. A vertical 
flight path optimization capability (also resident in the advanced FMS) will 
generate profile data that can be readied for display and accessed by the crew. 
Access will be either at crew discretion, or in response to suggestions based on 
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the T AND AM system's prediction of significant consequences of the upcoming 
vertical maneuver (e.g., underflying a crossing altitude). 

Again because of the design philosophy followed, the working decision has been 
to have the FMS share its display/control head with the Data Link system, thereby 
obviating the need to identify another acceptable location for an MCDU on the 
flight deck. This co-location of FMS and Data Link was also adopted because of 
the interaction-intensive sequences that would necessarily obtain between the two 
systems during clearance negotiations. Also, using the common MCDU, uplinked 
clearances in formats quite similar to their eventual representations on FMS pages 
will be easily and accurately inspected by the crew. With the development of an 
effective message prioritorization and annunciation scheme, this display/control 
co-location will constitute the core of an efficient and reliable functionally 
integrated system. 

The FMS's MCDU, as shown in Figure 7, will generally resemble other advanced 
MCDU designs except for space allotted for the co-location of the dedicated Data 
Link controls. Additionally, specialized formats, modes, line-select settings, etc., 
will be required to support advanced functions such as 4-D clearance 
negotiations, and other FMS- and Data Link-related interactions with the 
TANDAM system. Similar accommodations will be required for non-clearance 
and other non-flight-critical communications, and for company business. 
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4-D clearance and associated guidance information will be presented on the 
Primary Flight and Navigation displays (PFD and ND). In addition to standard 
tactical flight parameters and direction, the PFD (see Figure 8) will also display 
4-D navigation mode selection, "bugs" associated with speed, heading, altitude, 
and vertical speed settings (determined by the pre-selected or currently 
operational 4-D maneuvers), and time-to-maneuver information when relevant. 
The ND will present its information on two general formats: A modified map 
mode that presents 4-D information, and various maneuver guidance and 
configuration change prompts (see Figure 9); and a vertical profile planning 
schematic (see Figure 10) used to assist the crew in their selection of guidance by 
showing vertical maneuver options, constraints, etc., and their associated fuel use 
and passenger comfort estimates 

Capabilities of the TANDAM System 

As conceptualized in this design effort, the TANDAM system will (in conjunction 
with other systems) perform sophisticated flight management functions, and will, 
in reaction to situational changes and general operational goals, customize its 
assistance to the crew, to other onboard systems, and to ATC. 

The TANDAM system will act to coordinate data base updates, prepare for 
anticipated events in the flight plan, and manage air-ground communications. 
Additionally, it will help coordinate, negotiate, and comply with the directives of 
ATC (principally generated by CTAS) while still endeavoring to optimize the 
flight plan for the aircraft. And, while much of this work would of course 
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FIGURE 8. PRIMARY FLIGHT DISPLAY, SHOWING 
4-D NAVIGATION INFORMATION 
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FIGURE 9. NAVIGATION DISPLAY, IN MAP MODE, SHOWING 
4-D NAVIGATION INFORMATION 
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FIGURE 10. NAVIGATION DISPLAY, IN VERTICAL PROFILE MODE 

SHOWING MANEUVER OPTIONS 
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involve automated functioning, the system will perform these activities in a 
largely advisory and assistance capacity, maximizing the expertise of the crew 
while unburdening them of time-consuming and distracting tasks. 

To perform these functions, the TANDAM system must possess a number of 
processing and control capabilities. These capabilities comprise two operational 
domains: The utilization of various communications functions, and the 
management of tactical and strategic elements of navigation and guidance 
functions. 

The TANDAM system's management of communications 

The TANDAM system will govern two critical aspects of communications 
activities: The monitoring and use of on-going situational communications, and 
the management of communications with ATC that pertain to clearances. The 
TANDAM system's situation-specific management of each of these classes of 
communication activity will now be described. 

Situational communications — In service of the TANDAM system s objective 
of optimizing aircraft and crew performance, it conducts a number of 
communications management activities. For example, in the operational 
environment envisioned for this advanced concept, the TANDAM system 
provides the FMS with runway and approach assignments that it obtains from 
ATIS (or its advanced equivalent) typically just before initial descent. This 
acquisition of final flight path assignment is timely as well as useful because it 
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affords the FMS substantial time to complete its flight plan, including the 
determination of optimal terminal area navigation. It also allows the FMS to 
calculate precise waypoint ETAs, etc., in preparation for rapid, yet optimized, 
negotiations with CTAS. Lastly, automatic processing of ATIS information 
eliminates the potential for crew errors caused by late or erroneous accessing of 
ATIS information (a very common cause of "getting behind the aircraft"). The 
TANDAM system determines when to obtain the appropriate ATIS information 
by considering flight plan information regarding approximate time until landing, 
and data base knowledge regarding the schedule for periodic ATIS updates. 

After this initial employment of ATIS data, the TANDAM system periodically 
monitors ATIS for any changes that might affect the newly established runway 
and approach assignments, etc. 

In a related communications management activity, the TANDAM system 
continually inspects data linked information for data that might significantly alter 
the current flight plan (e.g., winds, weather). In a more advanced version of this 
capability, the source of this uplinked information would be CTAS - which 
would itself be sending a synthesis of data recently received from other nearby 
aircraft and other sources. Whatever the source of this data, the TANDAM 
system would have the job of assessing the implications of the new information. 
For example, if the TANDAM system receives information about severe clear air 
turbulence at a soon to be crossed altitude near, say, the SMO VOR - and the 
system notes that this VOR is closely abeam the aircraft’s future flight path - it 
can inform the crew about the likely occurrence of turbulence down route. 
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Clearance communications - The principal communications activities 
managed by the TANDAM system are those involved in the negotiation and 
acceptance of the complex clearances issued by CTAS. In these activities, the 
TANDAM system notes the reception of a CTAS clearance, and interrogates it 
for priority level and anticipated data processing requirements (e.g., changing a 
crossing altitude while maintaining the crossing ETA would involve new 
calculations by the 4-D component of the FMS). In the typical case, the 
TANDAM system then loads the clearance parameters into an FMS holding 
buffer ready for processing. Based on priority information and time available to 
comply, the TANDAM system determines whether to consider evaluating the 
clearance for optimality (in terms of aircraft performance), in short, the system 
decides whether it should propose a negotiation of the clearance. The system 
informs the crew of the clearance, the time until compliance is required, and 
whether it recommends negotiation of the clearance's parameters (while still 
abiding by its overall intent). In cases where the crew elects to evaluate the 
specifics of a clearance (for possible negotiation), the TANDAM system submits 
the buffered clearance data to the FMS and requests an estimate of an optimized 
compliance with the relevant waypoint(s), etc., and ETA(s). The system also 
reminds the crew to communicate compliance with the intent of the clearance, 
and their interest in negotiating the specific means of compliance. The resulting 
FMS solution (e.g., a delayed and steeper descent that still makes a particular 
waypoint on time and saves X pounds of fuel) is made available to the crew for 
approval, and is readied for downlink in the negotiation process. Upon reception 
of CTAS approval, the modified clearance is WILCOed by the crew. The system 
(with crew consent) directs the FMS to edit the flight plan and execute the 
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modified clearance. As the compliance point is reached (e.g., at top of descent), 
TANDAM system ensures that actual clearance data (e.g., exact time and 
location of descent initiation) is downlinked to CTAS. 

The TAN DAM system’s management of navigation and guidance 

Several significant navigation and guidance functions are assisted or managed by 
the TANDAM system. These functions support a number of related activities: 
clearance negotiation and compliance; anticipation and reaction to situational 
changes connected to aircraft performance and environmental factors; and crew- 
initiated modifications to flight path management. These activities range in 
purview of control from relatively tactical to clearly strategic, and they therefore 
involve both FMS and FMCP-oriented governance of flight control and guidance. 
Moreover, the form of accommodation the TANDAM system will afford these 
navigation activities is greatly constrained by phase of flight and type of function. 


Navigation management and clearance negotiation - As was mentioned 
briefly in describing the TANDAM system's support of communications 
functions, the system ensures that a newly cleared flight profile appropriately 
modifies the FMS's existing flight plan, including all requisite changes in flight 
parameters relevant to 4-D compliance. To support the FMS, the TANDAM 
system first evaluates data on current environmental conditions (obtained from 
sensors and from uplinked reports) and aircraft performance, and then integrates 
this information with clearance directives. This precise, updated information is 
used to edit the existing flight plan, modifying the flight path and schedule as 
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necessary. In cases where CTAS clearances involve modifications of the vertical 
flight regime, a computational module of the FMS that is specialized for 
determining optimal vertical maneuvers (in terms of the aircraft’s current 
performance characteristics) generates a range of solutions that comply with the 
clearance. The T AND AM system then directs the FMS to estimate passenger 
comfort (based on speed, vertical rate, anticipated turbulence, etc.) and fuel 
savings for this range of solutions. The TANDAM system readies the solution set 
and accompanying passenger comfort and fuel savings estimates for presentation 
to the crew, along with recommendations when appropriate. 

The TANDAM system's "cognizance" of flight phase substantially influences its 
support of the clearance negotiation function. For example, the previously 
described procedure (in the discussion of communications functions) for the 
TANDAM system’s management of negotiating a clearance was representative of 
clearances issued while an aircraft is at altitude, transitioning from Cruise to 
Descent phases of flight. In contrast, clearance negotiation procedures conducted 
in the terminal area would be automatically modified to be more conservative in 
several important respects. Operation at low altitudes and slow speeds, greatly 
delimited maneuvering options, and increased proximity of traffic necessarily 
constrain the TANDAM system's role in clearance negotiation. In the terminal 
area, then, the TANDAM system would consider negotiation only when such 
negotiations could clearly serve efforts to lower workload, improve or maintain 
situation awareness, increase safety margins, or better satisfy scheduling 
preferences. Thus, criteria for the negotiation of terminal area clearances will 
not (as in initial Descent) emphasize fuel savings, or perhaps even passenger 
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comfort. Instead, negotiations with ATC will be largely limited to supporting 
such activities as: Providing ATC with accurate ETAs, etc., to negotiating final 
clearances as early in the approach as possible; informing ATC of the aircraft’s 
readiness for reaching the outer marker at any of a range of ATC-determined 
arrival times; and providing ATC with aircraft readiness status for potential 
ATC-instigated changes to alternate runways, etc., or even for crew-initiated 
negotiations for such runway changes when safe and advantageous. 

As an example of this process, Figure 1 1 depicts a small segment of the 
TANDAM system’s functioning at a very general level. Specifically, two 
interrelated functions are schematicized. For one function, the flow diagram 
shows the situational triggers (in one of the cases, the aircraft's proximity to a 
significant waypoint, BAYST, and its requisite altitude of approximately 10,000 
feet) that cause the TANDAM system's criteria for recommending clearance 
negotiations to be modified. In this example, the clearance is optimized for 
terminal area (as opposed to Descent phase) navigation. Secondly, the diagram 
sketches out the broad factors addressed by the TANDAM system whenever it 
must consider recommending a negotiation of a clearance's specific parameters. 

In both functions, the TANDAM system interacts with three context-relevant data 
sources: The Flight Plan Data Base, containing all significant navigational and 
regulatory information germane to the flight route; the Data Link system 
through which CTAS-generated clearances and environmental reports will be 
received; and the aircraft's sensors and onboard systems that provide positional 
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FIGURE 11. PARTIAL SCHEMATIC OF A SUGGESTED 
FUNCTIONAL ARCHITECTURE FOR THE T AND AM SYSTEM 
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FIGURE 11. - Concluded. 
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information, performance data, and system status reports. Also evident in this 
depiction is the TANDAM system's critical reliance on the 4-D capable FMS. 

(The reader is cautioned to understand that this schematic is not meant to be 
comprehensive or exhaustive, and does not presuppose a given programming or 
computational approach. Rather, its purpose is simply to give a "flavor" for the 
general logic involved with the notion of context-sensitive automation.) 

Navigation management and position on flight plan - The TANDAM 
system performs a number of functions designed to keep track of and modify the 
aircraft's progress in the flight plan, to prepare for upcoming activities, and to 
inform or remind the crew about the options available to them at various points 
along the planned route. For example, in 4-D navigation, the TANDAM system 
monitors progress on the flight path (i.e., performs trajectory tracking), 
automatically performing minor adjustments that keep the aircraft on route and 
on schedule. When a particular adjustment would exceed a context-sensitive 
tolerance, or when such an adjustment might have a significant effect on 
anticipated workload, etc., the TANDAM system will inform the crew and offer 
options appropriate to the situation. 

More generally, the TANDAM system monitors position and time on the flight 
path, and compares this information with a flight path data base which stores all 
expected significant aircraft events. The TANDAM system determines whether 
actual events occur within the expected (data base) parameters, and notes any 
deviations from the predicted events, reporting them to the crew when necessary. 
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Additionally, the TANDAM system uses this monitoring function to help it 
anticipate and prepare for upcoming events. Thus, for example, when the system 
notes that the aircraft is about to enter an ATC sector handoff area, it 
automatically looks up and loads the new ATC frequency into a pre-select buffer 
for crew instigation. Similarly, in those terminal areas where ATC is known to 
provide the approach assignment relatively late (thus potentially increasing 
workload levels at inopportune times), the TANDAM system can look up possible 
approaches (given the already cleared descent and arrival route, approach 
restrictions due to winds, visibility, noise abatement, etc.) and rank order them in 
terms of probability of assignment. And, in cases where the most probable 
approach is appreciably more likely than its competitors, that approach can be 
loaded into an FMS pre-select buffer. 

At altitude, the TANDAM system's monitoring of progress on the flight plan 
allows the system and the FMS to maintain running estimates of position and time 
'windows' for maneuver execution such as deceleration schedules, points for 
speed break deployment, etc. In the terminal area, monitoring flight path 
progress also enables the system (via the FMS) to generate running solutions for 
points by which slats, flaps, and landing gear must be deployed, and for times 
associated with minimum altitudes and speeds to be achieved, etc. 

As was mentioned previously, the TANDAM system also monitors the aircraft's 
terminal area flight path progress when the system is calculating running 
solutions for possible runway changes late in the final approach. In such cases, 
the TANDAM system considers the aircraft's position on its flight path, the 
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current environmental and traffic conditions, and relevant airspace regulations in 
order to precisely determine several important context-sensitive parameters, 
among these being: 

- The point on the current approach by which the FMS must have the alternate 
runway's step-over maneuvers calculated, (in preparation for the earliest 
probable runway change clearance); 

- The point on the current approach at which a step-over maneuver to the 
alternate runway would also involve significant speed and/or altitude changes, 

and, 

- The points along the current (and alternate) approach by which checklists 
would have to be accomplished, ILS capture, centerlines, etc., would have to 
be established, and missed approach sequences would have to be loaded into 
pre-select. 

The T AND AM system's integration with other systems 

As was discussed earlier, the TANDAM system will rely on several advanced 
systems to performance its advisory and assistance functions. This reliance on 
supporting technologies will also depend on highly integrated software/hardware 
systems capable of accurately and rapidly sharing data sets and processing 
routines, and maintaining functional redundancy and safeguarding schemes. And, 
while the large majority of these supporting capabilities currently exist in limited 
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forms, it is clear that substantially advanced versions of these systems would have 
to be in place in order to enable the TANDAM system to fully function. 

The TANDAM system’s integration with the Flight Management 
System 

As has been mentioned, the TANDAM system requires substantial coordination 
with an advanced FMS. In addition to current capabilities, this FMS will (in 
order to parallel and complement CTAS capabilities) also have to be capable of 
highly accurate and flexible 4-D navigation, demanding rapid and continual re- 
calculation of the aircraft's current and future flight path, and its ETAs. These 
calculations of time and position information - coupled with situation-specific 
data from onboard systems and sensors, from the flight plan data base (e.g., 
crossing restrictions), and from communications uplinks — will be used by the 
FMS to continuously recalculate precise trajectory and speed solutions necessary 
for 4-D maneuvers and aircraft performance optimization. In particular, the 
FMS will have to be capable of generating and managing vertical profile 
sequences that optimize the aircraft's vertical maneuvers, since CTAS is currently 
slated to provide only nominal vertical flight paths in such clearances. The 
TANDAM system and the FMS will ensure that these 4-D maneuver solutions are 
constrained to preserve acceptable passenger comfort and crew workload. This 
4-D maneuver management function (and, in particular, management of the 
vertical regime) will be accomplished by means of two critical capabilities: The 
FMS’s highly integrated coordination with ATC's CTAS (which will supply 4-D 
clearance criteria, including route changes), and the employment of an FMS- 
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resident algorithmic system (similar to that employed in ATC's ground-based 
system) specialized for constructing aircraft-optimized 4-D vertical maneuvers 
still compliant with ATC directives. These capabilities will also enable the FMS 
and the TANDAM system to assist the crew in responding to unforeseen events 
(e.g., pop-up aircraft) by being ready to provide online recalculations, data base 
preparations, etc., for facilitating time-critical decision-making. 


The TANDAM system's integration with communications systems 


In addition to processing sensor, navaid, and performance data, the TANDAM 
system communicates with ATC and company sources. In this regard, the 
TANDAM system relies heavily on an advanced Data Link system capable of 
communicating complex CTAS 4-D clearances, rapid ATC/crew negotiations, and 
non-flight-critical and company business. Additionally, the Data Link capability 
will support a background-level continuous conduit responsible for sending and 
receiving aircraft, environmental, ATC, and company data (referred to in the 
flight scenarios presented later as the Most Current Data Exchange Transmission 
(MCDET) system). Information downlinked by MCDET will include: 

- Weather 

- Turbulence levels 

- Wind direction and speed 

- Temperature 

- Barometric pressure 

- Estimated visibility 


66 


- Aircraft position, altitude, speed, and vertical speed 

- Course and flight plan data, including waypoint ETAs 

- Engine and performance data 

- Weight, and fuel remaining 

- Requests for non-time-critical company, and ATC data 

- Certain clearance negotiation data 

Uplinked information would include: 

• Predicted weather, turbulence, wind, etc., down-route 

• Non-time-critical company information, and ATC queries 

• Certain clearance negotiation data 

This data is used by the TANDAM system and the FMS to update the onboard 
flight plan data base, and to provide ATC with the most useful situational 
information available. ATC, in turn, will use these continual reports from 
individual aircraft to update its data bases, and, consequentially improve its 
ability to predict aircraft spacing margins, potential conflicts, arrival times, and 
general environmental conditions. 

The TANDAM system's integration with the user interface 

The functional integration of the TANDAM system with an advanced crew 
interface is fundamental to the automation s utility. This crew interface — a 
functionally integrated system of annunciators, displays, and controls that helps 
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preserve crew awareness of, and prerogative over, the TANDAM system s 
actions and intentions - is integrated with the TANDAM system in several 
respects. The TANDAM system will interact with the crew to assist in making 
decisions, alleviating or re-aggregating workload, and enhancing situation 
awareness. This assistance is possible as a result of the TANDAM system's 
continual "awareness" of situation-specific mission events. In this assistance role, 
the TANDAM system tailors the organization of information and 
recommendations to be readied for presentation to the crew, such that only 
relevant, vital information is proffered first; additional background, secondary 
considerations, etc., are provided only upon request (or after crew acceptance of 
the automation's suggestions). To ensure against over-reliance on this automated 
assistance, the TANDAM system is integrated with the crew interface system such 
that it continually has available for the crew information regarding the status of 
currently operating automated routines. Moreover, this information also clearly 
reflects the automation's processing so as to give the crew an understanding of the 
system’s "mental" model and "intent." Where applicable, the TANDAM system is 
ready to report the potential consequences of its operation. When these 
consequences significantly exceed nominal expectations, the TANDAM system 
alerts the crew without waiting for their inquiries. 
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OPERATION OF THE TANDAM SYSTEM IN REPRESENTATIVE 
DESCENT AND APPROACH SCENARIOS 


As mentioned previously, three representative Descent and Approach scenarios 
were created in order to demonstrate how the TANDAM system would function 
in accord with the onboard systems, the crew, and ATC. These scenarios, all 
based on modified versions of published arrivals and approaches, used Los 
Angeles' International (LAX) and Orange County's John Wayne (SNA) airports. 
These airports were used because MDC research personnel were already familiar 
with ATC procedures in the surrounding Los Angeles-area terminal airspaces 
(having previously interviewed and observed controllers at both facilities). The 
existing arrival/approach sequences are heavily flown, and all are known to 
demand fairly substantial workloads, even in ideal conditions. ATC-directed 
deviations from the published flight paths are common, some occurring in 
virtually every approach into these highly trafficked airports. Even runway 
changes (at LAX) occur with a relatively high frequency, and thus must, to 
varying degrees, be anticipated in any approach. And, while the number of ATC 
interventions contrived for these arrival/approach sequences are probably 
unrealistically high (in order to demonstrate significant capabilities of the 
TANDAM system), their type and placement are quite representative of 
clearances anticipated under CTAS governance. 

The scenarios, presented in three multi-page tables (Tables I, II, HI), are each 
arranged in an abridged function timeline format, moving from one significant 
mission event to the next. For each time- and/or fix-marked event, relevant 
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ATC/aircraft communications, the TANDAM system's functioning, and crew 
involvement are described as appropriate. When significant aspects of 
TANDAM's activities warrant special focus, selected Navigation Display formats 
are presented. 

The SADDE FOUR Arrival into LAX 


The first scenario, described in Table I, is based on the SADDE FOUR Arrival 
STAR into LAX. In keeping with likely ATC planning for CTAS-govemed 
airspace, the arrival has been modified to be a profile descent. The modified 
SADDE FOUR is shown in Figure 12. In this scenario, it is assumed that CTAS 
is fully operational and is directing all navigation, sequencing, and spacing 
guidance for the aircraft on its descent and approach. The aircraft is equipped 
with an advanced Data Link system, as well as with the TANDAM system and an 
FMS capable of 4-D navigation. 

A number of clearances are demonstrated in this scenario. At altitude, three 
major 4-D clearances are issued by CTAS; Two expedited descents designed to 
make the aircraft attain fixes at times substantially earlier than planned; and one 
route stretch clearance designed to make the aircraft late, relative to the revised 
plan. In these three cases, the scenario in Table I shows how the TANDAM 
system might assist the crew in evaluating, negotiating, and complying with the 
ATC directives - and still optimizing the flight plan for aircraft performance 
and passenger comfort. 
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LAX 



FIGURE 12. SCHEMATIC FOR THE SADDE FOUR ARRIVAL INTO LAX 
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In the LAX terminal area, the scenario depicts the aircraft on its cleared 
approach. However, due to various unforeseeable events, the aircraft's approach 
is repeatedly interrupted and changed by ATC. In each of these cases, the 
scenario describes the TANDAM system's efforts to keep the crew aware of the 
latest situation and the aircraft configuration, and poised to respond appropriately 
to the eventual final clearance. 
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FIGURE 13. NAVIGATION DISPLAY, IN MAP MODE, 
SHOWING THE SADDE FOUR PROFILE DESCENT 
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make the 4D FIM clearance. comply with clearance (and 
Cost indices and estimated crew members mentally note 
passenger comfort levels are that SYS jibes with their own 
also provided. informal appraisal). 
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SYS readies selected descent Crew authorizes downlink of 
for downlink; updates ETA, descent profile data, 
profile, based on actual TOD. 
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FIGURE 15. NAVIGATION DISPLAY, IN VERTICAL PROFILE MODE, 
SHOWING CREW SELECTION OF DESCENT PROFILE FROM TOD TO FIM 
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version of clearance. Crew 
commands SYS to initiate 
negotiation. 
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FIGURE 16 . NAVIGATION DISPLAY, IN VERTICAL PROFILE MODE, SHOWING MANEUVER 
OPTIONS FROM REYES, THROUGH FIM ALTITUDE RESTRICTION, TO SYMON 
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FIGURE 17. NAVIGATION DISPLAY, VERTICAL PROFILE MODE ZOOM IN, SHOWING 
MANEUVER OPTIONS FROM REYES, THROUGH FIM ALTITUDE RESTRICTION, TO SYMON 
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plus 43 seconds. 
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Acknowledgement of 
clearance and acceptance of 
intent are downlinked to 
CTAS. 


TRK M30J MAG FIM 2.5NM :00.3 
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FIGURE 18. NAVIGATION DISPLAY, IN MAP MODE, SHOWING CTAS- 
AMENDED ROUTE FROM FIM TO SADDE 
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straight acceptance. 
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FIGURE 20. NAVIGATION DISPLAY, IN MAP MODE, SHOWING APPROACH TO LAX 

RUNWAY 24R FROM SMO 
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FIGURE 22. NAVIGATION DISPLAY, IN MAP MODE, SHOWING POINTS BY WHICH SLATS 

FLAPS, AND LANDING GEAR ARE TO BE DEPLOYED 
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Crew evaluates SYS data and 
approves downlink to ATC. 
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FIGURE 23. NAVIGATION DISPLAY, IN MAP MODE, SHOWING SUSPENDED CLEARANCE 
TO LAX RUNWAY 24R, AND POSSIBLE ALTITUDE AND SPEED HOLDS 
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FIGURE 24. NAVIGATION DISPLAY, IN MAP MODE, SHOWING NEW CLEARANCE 
TO LAX RUNWAY 24R, INVOLVING TURN TO BASE AT SMO/D15 
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resulting flight path possible revised base/final 

discontinuity. maneuvers, waypoints, etc 

for both runways. 
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FIGURE 25. NAVIGATION DISPLAY, IN MAP MODE, SHOWING EMERGENCY CANCELLATION 
OF CLEARANCE TO LAX RUNWAY 24R, JUST PRIOR TO TURN TO BASE AT SMO/D15 
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FIGURE 26. NAVIGATION DISPLAY, IN MAP MODE, SHOWING SOONEST POSSIBLE 

CLEARANCES TO LAX RUNWAYS 24R AND 25L 
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The KAYOH TWO Arrival into SNA 


In the second scenario (presented in Table II), the aircraft follows the KAYOH 
TWO Arrival STAR into SNA, and transitions to an approach that takes it above 
and across the final approach course (see Figure 27). The aircraft is instructed to 
continue on its current heading, awaiting vectors to be turned downwind and then 
to base, in order to intercept the SNA localizer. In contrast to the first scenario, 
the TRACON for SNA (Coast TRACON) is not assisted by CTAS, and does not 
have an operational Data Link ground system. To add to ATC's difficulties, it is 
responsible for a large and varied population of aircraft types and capabilities, 
owing in large part to SNA's proximity to other major civilian and military 
airports. The aircraft is again equipped with the TANDAM system and the 4-D 
navigation-capable FMS. 

This scenario depicts the assistance of the TANDAM system in an ATC 
environment not appreciably different from present-day capabilities. The 
TANDAM system helps the crew comply with last-minute clearances, and 
cancellations of these directives. Additionally, the scenario shows how the crew, 
TANDAM system, and FMS together might assist ATC in determining a useful 
4-D clearance for the aircraft's final approach. 


108 



FIGURE 27. SCHEMATIC FOR THE KAYOH TWO ARRIVAL INTO SNA 
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prior to KAYOH) after crossing the final 

approach course (i.e., after 
passing ABEAM LEMON). 
ATC advises crew to expect 
vectors after ABEAM LEMON. 
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currently planned point of 
achieving 4000 feet to a 
(crew-determined) fix 1 nm 
prior to ABEAM LEMON (i.e., 
1 nm after JOG IT). 
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stored in a secondary buffer 
available to load into pre- 
select at crew command. 
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FIGURE 28. NAVIGATION DISPLAY, IN MAP MODE, SHOWING TAND, 
GENERATED RUNNING SOLUTIONS TO SNAKE FROM ABEAM LEM 
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to SNAKE after approximately 
15 : 07 : 33 . 
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FIGURE 29. NAVIGATION DISPLAY, IN MAP MODE, SHOWING TANDAM- 
GENERATED RUNNING SOLUTIONS TO SNAKE FROM ABEAM LEMON/DI 
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15:02:31 Crew ROGERS clearance; Crew selects SYS-calculated 

informs ATC that turn to solution to SNAKE. 

downwind will commence 

immediately. 


TRK [258\ MAG SNAKE 15.6nm/:05.2 
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FIGURE 30. NAVIGATION DISPLAY, IN MAP MODE, SHOWING 
CLEARANCE TO SNA RUNWAY 19R 
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15:03:38 Crew directs SYS to calculate 

running 4D solutions for the 
shortest path to SNAKE. 
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FIGURE 31. NAVIGATION DISPLAY, IN MAP MODE, SHOWING CANCELLATION 
OF CLEARANCE TO SNA RUNWAY 19R, AND TANDAM- GENERATED RUNNING 

SOLUTIONS TO SNAKE 




Preparations for a Possible Runway Change During an Approach to 
LAX 


This third scenario (depicted in Table III) describes a portion of a standard 
profile descent and approach (the LAX CIVET TWO Arrival) in order to 
demonstrate how the TANDAM system might assist the crew in preparing for a 
possible change in assignment from the currently active 25 Left mnway to the 
possible alternate 24 Right runway (please see Figure 32). Both CTAS and Data 
Link are fully operational. However, in this scenario, the local conditions 
quickly become significant factors, with the aircraft flighting a moderate 
headwind and flying into steadily worsening weather as it approaches LAX. In 
fact, the crew's (and ATC's) major concern involves the possibility of a change in 
runway assignments from 25 Left to 24 Right necessitated by airport-area 
visibility threatening to drop from Category II to Category III ILS status. In this 
scenario, the TANDAM system assists the crew in preparing for the possible side- 
step to 24 Right. The TANDAM system monitors positions and times from each 
of the runways, and helps the crew perform preparatory activities when they 
need to be done, and in an order that optimizes workload and preserves crew 
options. These activities — calculating a running solution for the step-over 
maneuver to 24 Right, following all approach constraints, noting significant 
maneuvering changes necessary if the alternate runway is assigned, establishing 
the last safe point for the step-over maneuver, and setting up for ELS changes, 
etc. — are all critically supported by the capabilities of the TANDAM system. 
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FIGURE 32. SCHEMATIC FOR A POSSIBLE RUNWAY CHANGE 
DURING AN APPROACH TO LAX 
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alternate; directs SYS to 
calculate running solutions, in 
pre-select mode, to 24R. 
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F RK [249J MAG ARNES 2nm :00 
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FIGURE 33. NAVIGATION DISPLAY, IN MAP MODE, SHOWING TANDAM-GEHERATED 
EARLIEST SOLUTION FOR SIDESTEP MANEUVER TO LAX RUNWAY 24R 







129 




130 


FIGURE 34. NAVIGATION DISPLAY, IN MAP MODE, SHOWING 
ACTIVE (25L) AND ALTERNATE (24R) APPROACHES TO LAX 
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SYS edits approach profile 
between FUELR and 
DOWNE. 
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ATC acknowledges crew's 
message; still believes 25L 
will stay above minimums. 
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FIGURE 35. NAVIGATION DISPLAY, IN MAP MODE, SHOWING TANDAM- 
GENERATED RUNNING SOLUTIONS FOR SIDESTEP MANEUVER TO LAX 

RUNWAY 24R FROM FUELR/D4.5 
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FIGURE 36. NAVIGATION DISPLAY, IN MAP MODE, SHOWING TANDAM -GENERATED 
LATEST SOLUTION FOR SAFE SIDESTEP MANEUVER TO LAX RUNWAY 24R 




TIME EVENT COMMUNICATIONS TANDAM SYSTEM CREW INVOLVEMENT 


0 

I i 

« "2 0 
co c co 

DC o <i) 

< Q - 

eo O o 

6 — 1 “ 
£ lO ® 

S w 3 

si’s 

> <0 g 


0 


0 
0 

1 

5 


0 

2 

8 

o 


£ 

3 

Q. 

s 

0) 

0 

—I 

in 

CM 

2 

0 

*3 

il 

O CL 


c 
o , 
Its 
0 

£ 

1 

g 

0 

O) 

c 


«*! 

o i. 

8 |- 

O E 

M~ O 

Si' 


* 

s 

DC 

5 


co 

>- 

CO 


Si 

.£ 7 


co 

0 


0 

o> 

c 

_Q 

o 

c 


i_ fc- ^ 

I "8 

il 

E E 

Q_ 8 

£ 2 
0 ‘ 

0 % 

a 3 

0 .h: 
<D 0 


o 

H 

< 

0 

3 

$ 

0 

o 


8 


DC -I 
^ in 

0 CM CM 


Iw 
0 ■*£ 
Q_.== 

& 8 . 

8 c 
*» ® ■ 
See 

.5 >%0 
V>£-£ 



oo 

5 

lD 

z 

<: 

o 

o 


o 

00 

cvi 


139 



HUNDA Inn 



140 


FIGURE 37. NAVIGATION DISPLAY, IN MAP MODE, SHOWING LOSS OF SAFE 

SOLUTION TO LAX RUNWAY 24R 
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TIME EVENT COMMUNICATIONS TANDAM SYSTEM CREW INVOLVEMENT 


CL 

04 

O 


<D 

To 

c 


<D 


ffi 2 

_ E c c* 

* ?C0 o 
W (b> C 
0^03 — 

— <0 05 < 1 > 
0> CA C U 

$|os 

fc_ ■” — -3 

O £ O) 


.0 . 

2 "S 
® 


8 


- £ 
o « 

85 

°i 

S®» 

: ~ rr»^« 


— w 
__ £>“0 

Pi 


o 

CO 

0) Q> 
CO 0 

3 § 

3 o 

a§ 

Sa 

J> §" 

o 75 
c c 

is 

k- Q) 

O c 


CQ 

K> 

£ 

s 

DC 

§ 




Cl 0 

i O jg ^ = 
: o Tff Ao 
1 cm X X: CO 

^■SS * 

i 3 co 01 cB 


O 

o 

S* 

oj ^ 

*+r ■£ 

° 9 " 

cd 


05 


1 


IS 

co o 
>■ 3 

CO CO 


CO 

0 

CL 

'M* 

OJ 


i 

o 


05 

c 


c 3 

CO O 

> 3 
CO CO 


I 

Q 


<0 

CM 

0 
CO 

01 


142 


SYS changes communication Crew notes 24R GS capture 
radio frequency. point; roles out of turn, at 

2200 feet and holding until 
GS capture. 


2491 MAG ROMEN 7.6nm :02.8 



143 


FIGURE 38. NAVIGATION DISPLAY, IN MAP MODE, SHOWING 
SELECTION OF LAX RUNWAY 24R FOR FINAL APPROACH 
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PLAN FOR EVALUATION OF THE TANDAM SYSTEM CONCEPT 


Content and Scope of the Evaluation 

The goal of the proposed test of the TANDAM system concept is twofold: To 
evaluate the potential for relevant operational benefit of such a system, and to 
identify possible shortcomings of the system as it is currently defined. As such, 
this evaluation most appropriately should be limited in scope, concentrating on 
major functional features of the proposed automation and their potential for 
utility in operationally critical (and representative) mission events. This test plan, 
therefore, takes as its objective, the goal of defining an investigation of the system 
concept's operational value in the context of a limited number of carefully 
designed flight scenarios depicting the CTAS-controlled commercial aviation 
environment assumed for the near future. 

Owing to the currently preliminary status of the TANDAM system concept, 
evaluations should entail part-task simulations of its principal functional features 
exercised in a moderate-fidelity operational environment. The major capabilities 
of the TANDAM system should be prototyped only to levels sufficient to 
determine their operational validity, and to determine the effectiveness of their 
performance in comparison to relevant baseline conditions. Only after success in 
such part-task/limited-prototype evaluations should the development of a full- 
scale TANDAM system prototype be considered for more comprehensive 
investigation. In this light, the test plan proposed herein should be considered a 
necessary and prudent, but not sufficient evaluation of this system concept. 
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Preparations for the Evaluation 


To conduct the part-task evaluation of the TANDAM system concept, several 
preparatory activities will be necessary. First, specific, limited implementation 
of the system concept in the context of an advanced flight deck will involve the 
development and refinement of an operator interface. This would include 
creating the actual means by which subjects can interact with the FMCP, FMS, 
and Data Link control heads to affect commands, call up information, etc. These 
control activities in turn, will of course need to be connected to software 
emulations and/or simulations of significant components of the crew station and 
ATC automation. Software modules must be created that are capable of 
replicating advanced FMS functions (including 4-D navigation and vertical 
maneuver management), Data Link communications, CTAS clearances (including 
4-D schedule constraints), and (at least) the principal management and assistance 
functions of the TANDAM system. These modules must have access to a fairly 
sophisticated relational data base that will contain the relevant parameters of the 
scenario's flight plan, and all the mission events and situational variables needed 
to trigger automated response. 

In addition to the development of the aircraft and ATC simulation/emulation 
capabilities, it will also be necessary to specify task timelines associated with the 
scenarios used in the evaluation. These detailed descriptions of the operational 
environment will be crucial to the precise, "in situo" definitions of the variables 
of interest and the associated performance measures used to evaluate them. So, 
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for example, the factor of "situation awareness" — a difficult concept to 
adequately define in the abstract - could be defined in relation to a particular 
mission event (e.g., negotiating a clearance), if the operational parameters of that 
event have been explicated. With "situation awareness" specified for the relevant 
mission event, the determination of how to appropriately measure it (while not 
trivial) would follow. 

Development of detailed timelines would contribute to two other essential aspects 
of the evaluation of the TANDAM system. For one, the timelines would be used 
to help specify the mission-event information stored in the relational data base. 
Thus, specific timing constraints, maneuver requirements, etc., would be 
available to assist in the development of the TANDAM system, FMS, and Data 
Link capabilities. Secondly, the timelines would, of course, allow for task- 
duration and relative workload comparisons between test conditions. 

Research Methodology 

Subjects 

Subjects will be commercial transport pilots currently flying FMS -equipped 
aircraft. Subjects will possess average levels of experience with this type of 
aircraft. They will be recruited from current line service situations, and will be 
paid for their participation. 
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Design 


The empirical evaluation of the TANDAM system concept will contrast three 
principal factors of interest: The type of Navigation Management, being 
accomplished using either an advanced Baseline Crew Station, or the TANDAM 
System's Crew Station; the type of ATC Governance, considering CTAS- and 
Non-CTAS-Govemed environments; and the type of Mission Function, 
evaluating performance in an At-Altitude Clearance, a Terminal Area Clearance, 
and a Preparation for Runway Change. Two different groups of subjects will 
operate the Baseline and TANDAM system's crew stations. Each group will fly 
two equivalent descent and approach scenarios, one governed by CTAS and the 
other by more current (non-CTAS) ATC control. The order in which subjects 
participate in these two scenarios will be counterbalanced to help control for 
possible carryover effects. The scenarios will each contain at-altitude and 
terminal area clearances, and preparations for a possible last-minute runway 
change. Each type of mission function in the scenarios will have been matched 
for rough position in the scenario timeline, number of maneuvers required (and 
their overall complexity), approximate number and type of fixes and restrictions, 
number and type of clearances involved, environmental conditions, and timing 
constraints. 

Dependent measures will include tracking and waypoint/fix arrival time accuracy, 
course, and specific maneuver tracking accuracy (in terms of rms errors), overall 
and clearance-specific fuel savings (in pounds of fuel), estimated workload, speed 
of responding to ATC clearances, navigation and guidance errors (related to data 
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input awareness and understanding of system processing, and anticipation of the 
automation's actions), and communications errors. Where appropriate for 
purposes of comparison between conditions (where, time, number of maneuvers, 
etc., may not be exactly equivalent), dependent measures will be analyzed in 
terms of percentages of deviations from optimal performance. 

Materials and apparatus 

As was mentioned in this section's introductory remarks, the evaluation will be 
conducted in a part-task simulation/emulation environment. The principal 
components of an MD-1 1 -class cockpit will be employed. However, a number of 
significant modifications will also be required. The FMCP will be modified to 
incorporate 4-D navigational and guidance capabilities, and a cursor control for 
the ND. The FMS MCDU (and associated pages) will be modified to 
accommodate the emulated construction and execution of 4-D navigation, and to 
provide a control head for the Data Link system. Interface formats and controls 
for the TANDAM system will also be provided (please see the system design 
section for details on these modifications). 

The evaluation software will have to possess part-task simulations of the two 
Descent/Approach scenarios, and the TANDAM system's functional capabilities. 
Additionally, the software will need to be able to (at least) emulate essential 
aspects of 4-D navigation and guidance (onboard and ground-based), and 
representative ATC (including CTAS) procedures. A Data Link emulation will 
be required to execute the resulting clearance negotiation sequences. Data base 


149 



support for these functions will need to be available. Flight plan information for 
the Descent/Approach scenarios will have to be provided to subjects for study 
prior to conducting the evaluation. 

Procedure 

Two sets of subject activities will comprise this evaluation. Firstly, subjects will 
receive thorough training (including practice) in the cockpit configuration to 
which they have been assigned. For all subjects, this training will include 
familiarization with the Descent/Approach routes, and with the FMS, FMCP (and 
associated formats), and Data Link system. All subjects will also be trained in 
4-D navigation operations, including clearance evaluation and negotiation. This 
training will cover CTAS- and Non-CTAS-Govemed ATC control. Subjects 
assigned to the TANDAM system's crew station will learn procedures and 
capabilities specific to its employment. 

The second activity, subjects' participation in the evaluation trials, will be 
conducted in separate sessions adhering to the counterbalancing assignments, etc., 
described in the Design section. When subjects have completed both scenario 
runs, debriefing interviews will be conducted. 
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Predictions 


Two general hypotheses are made with regard to this evaluation: Use of the 
TANDAM system will result in superior crew performance and situation 
awareness when compared to use of the conventional advanced (i.e., Baseline) 
crew station; and crew execution of descent and approach functions in the CTAS- 
Govemed environment will be superior to analogous crew activities when not 
governed by CTAS. These general hypotheses will be supported by several 
specific predictions. 

In the At-altitude Clearance conditions, superior performance for the TANDAM 
system is predicted to be demonstrated by fewer and smaller deviations from 
ATC-assigned waypoint/fix arrival times, more accurate tracking and 
maneuvering, and larger estimated fuel savings. These benefits are predicted to 
be even more substantial when CTAS is in operation. 

Performance resulting from the use of the TANDAM system in the terminal area 
is also predicted to be superior to performance in the baseline crew station 
conditions. Again, smaller deviations from ATC-determined arrival times, and 
more accurate tracking and maneuvering, will evince the TANDAM system's 
utility. Additionally, lower and better distributed workload should be indicated 
by pilots employing the TANDAM system. 

For functions involved in preparing for a possible runway change, the 
automation-assisted conditions should, once again, demonstrate better crew 


151 



performance and awareness than the conventionally equipped (i.e., baseline) crew 
stations. While superior time-at-waypoint, and control activity accuracy are once 
again expected, the critical predictions of superiority here involve the TANDAM 
system's assistance with preparations in anticipation of a last-minute clearance. 

As such, it is hypothesized that subjects using the TANDAM system's crew station 
will exhibit fewer preparation omissions, fewer input and selection errors, and 
fewer navigational confusions than will subjects using the baseline crew station. 
Furthermore, cockpit activities in the TANDAM system conditions will more 
closely approximate ideal sequencing and timing of essential preparations (e.g., 
adhering to scheduled speed reductions, establishing ILS capture, and correctly 
setting all maneuver pre-selects for the alternate runway). Because of these 
preparatory advantages, crews using the TANDAM system should be well aware 
of crucial altitude, speed, and positional differences between the assigned and 
alternate runways. 

In summary, future real-world implementations of the TANDAM system and 
CTAS should expect many operational improvements in the National Airspace 
System. These enhancements should include fewer and less serious errors 
associated with automation usage, fewer consequent clearance-related violations 
(e.g., altitude "busts"), improved situation awareness for the crew (and for 
controllers), and better crew cognizance of navigation and guidance automation, 
especially with regard to anticipating the automation's actions. 
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COMMENTS AND CONCLUSIONS 


SOME FINAL CONSIDERATIONS 

The present study has endeavored to define a concept for an automated system 
that assists the crew in executing navigation, guidance, and communications 
functions during descents and approaches. This automated system, the TANDAM 
system, has been designed to take substantial advantage of situation-specific 
elements in the aircraft mission. Moreover, the design and development of this 
system has attempted to follow human-centered design principles in its 
construction of the automation's operational capabilities and associated interface 
elements. The functional integration of the TANDAM system with 4-D 
clearances, and CTAS in particular, reflects a design philosophy of ensuring the 
development of a design concept well situated in the next generation of the 
National Airspace System. 

This having been said, however, it should be remembered that the automated 
system defined in this program has been developed in a solely analytical fashion. 
It is, therefore, a legitimate concern that problems may have been overlooked 
which were not apparent in the design effort and have remained so, owing to the 
lack of critical evaluation under dynamic, temporally realistic conditions. For 
this reason, the test plan proposed in the preceding section (or some derivative 
thereof) is recommended as the next step in the development of this system. 
Whatever evaluative means is used, it is readily apparent that there is still 
substantial work to be done to verify that the system is viable. 
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Also provided in this research effort is a set of guidelines tailored to the 
challenges of automation design. Given the design philosophy adopted herein, it 
was no surprise that many of these guidelines directly addressed issues arising 
from cases in which automation is designed to take advantage of situation-specific 
information to operate at its fullest potential. These guidelines have been 
expressly written for crew system designers, but it is hoped that their 
applicability will extend to other engineering practitioners as well. 

AUTOMATION AND THE NATIONAL AIRSPACE SYSTEM 

In the course of conducting these activities, a number of collateral "lessons 
learned" have emerged. Chief among these is that it has become quite evident 
that, while future automation will benefit from being responsive to all aspects of 
the flight environment, none is perhaps more useful than automation that is able 
to accommodate the rather substantial capabilities of next-generation ATC. The 
advent of CTAS will enable coordinated, safe, and efficient 4-D navigation for 
aircraft in virtually every aspect of descent, approach, and landing. CTAS, if 
allowed to operate as it has been designed, will improve spacing control and 
sequencing efficiency, while minimizing average scheduling delays for all 
involved aircraft. But this sophisticated set of capabilities will not be maximally 
exploited if the modem commercial transport's airborne communication and 
navigation systems are not equally competent partners in the precise control 
necessary for accurate 4-D navigation. To consider just one example, an 
aircraft’s airborne systems will need to be capable of rapidly evaluating ATC 
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clearances and determining the aircraft’s optimal response in order to allow 
negotiation, when desirable. And air traffic controllers, for their part, will need 
to effectively customize their directives to optimally control aircraft of that vary 
greatly in their ability to comply with such clearances. 

With regard to the flight deck automation itself, it is evident that software 
systems that can utilize situational cues are at a distinct advantage over systems 
that cannot. Even without recourse to more sophisticated computational schemes 
(e.g., using mental models of pilot workload), the TANDAM system defined in 
this report shows every indication of improving responsiveness to mission plan 
demands, and to unanticipated events as well. The prospect of eventually 
employing such advanced computational approaches promises the development of 
automated systems that more intelligently anticipate and respond to mission 
objectives and environmental conditions, and that do so in ways that complement, 
and even enhance, human abilities. 
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APPENDIX: 

GUIDELINES FOR THE DESIGN OF ADVANCED 
AUTOMATED SYSTEMS WITH A SPECIAL EMPHASIS 

ON ADAPTIVITY 

ISSUES REGARDING DESIGN PHILOSOPHY AND GUIDELINES 

In this appendix, guidelines are presented for the design of automated systems. 
As the title of the document indicates, special emphasis has been placed on 
developing guidelines that address design issues relevant to situational and pilot- 
state variability, and to the automation's ability to adapt to these contextual 
factors, when necessitated by mission requirements. 

For the sake of conceptual continuity, the introductory comments, and the 
discussion of design assumptions and philosophy presented in the body of the 
report are now repeated (in modified form) at the beginning of this appendix. 

Introductory Comments 

Recommendations and guidelines for the effective design of automated systems 
share a number of important characteristics with other design guidelines. For 
example, since the human operator often interacts with the automated system, 
guidelines regarding the design of an interface are typically relevant. And, since 
the automated systems are specialized software and/or hardware systems residing 
in the overall avionics system, guidelines for the design of such technologies are. 
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of course, pertinent. What makes automation design unique, however, is the need 
to establish guidelines advising designers about translating operational and 
functional requirements into routines for gathering and interpreting data, 
applying rules, etc., and subsequently executing advisories and/or commands to 
the aircraft and crew. In this sense, design guidelines for automation must 
consider both the system's states and the crew's strategic awareness and 
understanding of those states. 

Thus, the desire to provide specific, concrete guidelines is often, of necessity, 
replaced with the goal of developing guidelines that keep the designer responsive 
to the general intent of the design requirement. For example, how a particular 
system is programmed may be irrelevant from a design point of view; however, 
how it acts (obtains information, processes it, makes interpretations and informs 
its users), as a result of that programming, is of central concern to the designer. 

It is essential to keep in mind that the designer of an automated system is (or at 
least should be) driven by one overriding concern: Satisfaction of mission and 
functional requirements. The means by which this automated system satisfies 
these requirements must follow two interrelated tenets: The designed system 
must be able to effectively accomplish the execution of its identified technical 
tasks (e.g., 4-D calculations to a fix must be accurate and timely), and it must be 
able to accomplish these tasks in ways that involve, inform, and assist the crew 
without also resulting in undue levels of workload, and while still ensuring an 
optimal level of situational awareness. Moreover, this second tenet, often 
referred to as human-centered design, demands that this inclusion of the human 
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operator go well beyond mere accommodation of his or her (unavoidable?) 
presence. Human-centered design endeavors to develop technologies that take 
advantage of human cognitive and perceptual strengths and preferences, and that 
help compensate for human limitations. These guidelines for the design of 
automated systems must direct the designer to remain cognizant of human skills 
and their possible utility in satisfying the mission and functional requirements. 

A human-centered approach to automation presupposes that the human operator 
possesses the critical skills and knowledge required for safe, efficient flight. 
Researchers and the pilot community both point to such crew assets as the crew's 
ability to learn from experience, to make quick, decisive judgements in uncertain, 
time-critical situations, and to cope with unanticipated, perplexing problems — 
even when these problems have, perhaps, never been encountered before, or 
when there may be no one "correct" solution. It is not surprising, therefore, that 
most sophisticated efforts in developing artificial intelligence and other "smart" 
automated systems focus on these same problem-solving and decision-making 
abilities. It is essential that advanced automated systems assist the transport crew 
in high-level tasks, if these systems are to be considered genuinely human- 
centered. But to be able to perform such functions, automated systems must be 
able to monitor and assess several classes of context-sensitive variables: the 
rapidly changing situation of the aircraft at any given point in its route, the more 
strategic elements of the mission plan (and modifications by ATC and other 
external conditions), the crew's cognitive and physical states, and their anticipated 
needs and preferences. In these important respects, human-centered automation 
must be adaptive, responsive, and accurate. It follows, then, that guidelines for 
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the design of automated systems will only be useful if they encourage designers to 
remain aware of the mission and its requirements, fully consider relevant human 
capabilities and limitations, and take advantage of the situational information that 
will allow them to optimize the functional relationship between the automation 
and the operators, in service of the mission’s goals. 

So, to summarize the discussion thus far, the determination of automation 
requirements should be based on a thorough understanding of mission 
requirements, operational constraints, and human capabilities and limitations. 

This understanding is essential since it is on its basis that the designer must 
determine what functions and activities, in what contexts, should be accomplished 
or assisted by an automated system. This understanding must be both 
comprehensive (in terms of mission goals) and procedural (in terms of specific 
crew and system decisions and activities) so as to provide the designer with both 
strategic and tactical goals for the system design. The understanding of the 
mission objectives and operational context — whether learned from flight phase, 
environmental factors, or pilot state — provide the cuing mechanisms for 
enlisting the assistance of the automated system, and for determining what data 
must be evaluated and what decisions and actions must be considered. 

Assumptions and Choice of Design Philosophy 

In any design effort, assumptions must be made regarding mission requirements, 
relative level of functional advancement over current capabilities, software and 
hardware capabilities, and extent of the system's impact on the integrity of other 
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cockpit systems, and on the crew's procedures. These assumptions in large part 
govern the designer's thinking in the design process, and greatly constrain the 
design philosophy adopted - the designer does well to make explicit the 
assumptions of the design goal and the consequent design philosophy being 
followed. Determination of these assumptions could come from any number of 
pragmatic, technical, or theoretical considerations. In human-centered design, 
assumptions must be the products of mission requirements and human 
information processing capabilities. 

In any automation design effort, several assumptions must be made for coherent, 
principled designs to be developed. Chief among these are assumptions 
regarding: 

- Software and hardware capabilities — in any design effort, critical 
technologies must be operational in the time frame envisioned for the 
automated system. 

- Determination of the extent of automaticity versus extent of human 
involvement — One decision crucial to the choice of design philosophy is 
determining the degree to which the automation will function 
autonomously, versus the degree to which dependence on human 
monitoring and intervention will be required. This issue of extent of 
automaticity is critical since the consequences of a poorly thought out 
philosophy in this regard can result, at one extreme, in ineffectual 
(minimal) automation and, at the other, in completely opaque and 
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surprising (maximal) automated control. Unfortunately, this decision is 
too often made on the basis of any number of peripheral criteria — 
technical feasibility, for example, or even simple expedience. From a 
human-centered design perspective, only the potential for reduced 
workload, maintained or increased situational awareness, and the ability to 
capitalize on mission-enhancing options should be determinants of the 
applicability and extent of automaticity. 

However, determining the appropriate extent of automated functioning is 
potentially complicated by other tenets of human-centered design. Consider, for 
example, two of Charles Billings' (ref. 4) general principles for human-centered 
automation: 

"To command effectively, the human operator must be involved, (p. 13)" 
"To be involved, the human operator must be informed, (p. 13)" 

Taking these principles at face value, one could reason that the more involved 
(and, by implication, informed) the human operator, the more in command that 
operator would be. But, since one of the typical motivations for deciding to 
automate is to unburden the operator from having to be cognizant of all aspects 
of a function, — that is, purposefully rendering the operator less informed about 
every detail of the function's execution — automating could easily be seen as 
lessening informativeness and involvement, and therefore being opposed to 
Billings' design principles. 
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The resolution to this apparent dilemma, of course, lies in what the operator is 
informed about. Billings is certainly not recommending that an automated system 
should tell the operator about every detail of that system's processing. Rather, he 
is recommending that the system (and any context-sensitive mechanisms 
supporting it) be crafted such that precisely and only the relevant events, states, 
etc., be interpreted for, and reported to, the crew. 

To re-couch the issue then, it is perhaps more accurate to say that the appropriate 
degree of automaticity is determined by the designer's success in first identifying 
the essential operational information required by the operator (for situation 
awareness), and then effectively presenting that information to the operator in the 
course of the system's execution of the automated function. In this regard, then, 
the designer cannot be free to make the arbitrary decision to specify more or less 
automated functioning — done correctly, such decisions can only result from an 
understanding of human information processing requirements, and the mission's 
functions. 

DESIGN GUIDELINES 

Analysis of Mission Functions and Determination of Requirements 

While not formally part of the design effort, functional analysis and requirements 
definition activities are (as the previous discussion attests) essential preparatory 
tasks, the results of which greatly shape the eventual design of the automated 
system. For this reason, it is recommended that a significant portion of any 
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design effort be devoted to a comprehensive treatment of these preliminaries. 
Several guidelines should be considered when conducting these activities. 


• Endeavor to identify functions, not tasks. Since the goal of the designer is 
to develop the optimal automated system, working from the more general 
information embodied in functions makes it less likely that the new design 
will be preemptively constrained to resemble existing tasks (i.e., existing 
means of accomplishing underlying functions). 

• When identifying functions, endeavor to identify contextual factors (e.g., 
phase of flight, weather, crew workload) that may influence how that 
function is accomplished. Especially note contextual factors that threaten 
to impede the effective and safe execution of that function and subsequent 
functions. 

• Do not limit functional analysis and requirements definition activities to 
modified time-line analyses of mission segments. Endeavor to include 
indirect information from pilot reports, incident and accident data, and 
reviews of technical research. Also, where appropriate, obtain part-task 
and in-situo training on relevant technologies and in relevant operational 
procedures. Periodically consult subject matter experts, and evaluate the 
opinions of these experts based on differences in line experience and 
general operational background, beliefs and biases, etc. 
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• When identifying functions, endeavor to identify functions that appear to 
be error prone (even when those errors are typically recognized by crews, 
or by onboard or ground-based systems). 

• When identifying functions, endeavor to identify functions (as currently 
instantiated in tasks) that demand high levels of workload or concentration, 
take significant amounts of time, or that interfere with, degrade, or do not 
promote situation awareness. 

• When identifying functions, endeavor to note contingency relationships 
between functions, especially when execution of a function has significant 
consequences for several concurrent or subsequent functions. In 
particular, look for cases in which the execution of a function determines 
or substantially restricts the options, performance, etc., of contingent 
functions, since such cases are logical candidates for automated assistance. 

• When identifying functions in existing systems, endeavor to note cases in 
which the same or similar functions are accomplished differently. In such 
cases, attempt to ascertain the reasons for these operational differences 
(e.g., due to situational changes such as differences in altitude or 
maneuvering area, or due to artifacts of previous design decisions such as 
executing a maneuver through an FMS input versus through a FCP 
command). Such functions may have situation-specific requirements for 
automated assistance. 
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• When instances of present-day automation are encountered, endeavor to 
ascertain the logic behind the automation, including the employment of all 
its modes and situations of operation. Rather than uncritically accept, 
question the implicit or explicit design decisions embodied in the 
automation in order to lessen the tendency to bias the design of new 
systems. 

Automated System Capabilities 

When determining the capabilities required of the automated system, the designer 
must consider (at least) two classes of capability: Capabilities related to mission 
functions and their operation in coordination with the crew and ATC, and 
capabilities related directly to the processing and interpreting of situation-specific 
information to be used in the cuing of automated routines. 

Operational capabilities 

• When determining operational capabilities required by the automated 
system, the scope of the automation's functional control must be identified 
(e.g., automated control of all landing maneuvers via an Autoland system) 
and every effort must be made to catalog this automated control's 
consequences on related systems and procedures. The potential 
consequences of the automation’s scope of control can include everything 
from the designer's intended improvements in operational performance, to 
unintended control over-rides and inadvertent activation (or inhibition) of 
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other systems. Test phase evaluative processes such as Failure Modes and 
Effects Analyses (FMEAs) are often used to identify the consequences of 
the newly developed system's implementation. Analytic processes similar 
to FMEAs should be used to evaluate automated system concepts early on 
in design. (This recommendation, of course, is easier said than done. For 
such evaluative processes to be effective, a rather sophisticated and 
comprehensive model of the proposed system [and the overall crew station] 
must already be articulated to some degree. It is a simple fact of most 
concept design efforts that this level of system specificity is not yet defined, 
In this more typical case, it is recommended that the designer endeavor to 
continually question and explore the potential consequences of the 
operational capabilities posited for the candidate system). 

• When defining operational capabilities of the proposed automated system, 
the designer should not be quick to abandon design concepts that meet with 
initial criticism or skepticism that is based on current operational realities 
or conventions. Instead, the designer should use these comments, 
objections, etc., as rather decisive feedback about the proposed design, and 
should consider them seriously and respond to them substantively. 
(However, this encouragement of innovation notwithstanding, the designer 
is reminded that the great majority of innovative concepts are legitimately 
rejected on technically, operationally, or pragmatically sound grounds.) 
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Adaptive capabilities 


• In cases where the designer has determined that context-sensitive automated 
routines would be advantageous to more effectively accomplish mission 
functions, the specific contextual cues required for these automated 
routines must be expressly identified and the feasibility of their 
implementations assessed. 

• When contextual information is under consideration as a cue for automated 
routines, the designer should endeavor to determine the relative predictive 
value of that information. While degree of predictability, per se, can not 
always be easily or accurately characterized, it is often possible to look for 
co-occurrence or precedence relationships between the to-be-automated 
function and potentially predictive contextual cues. In many cases, such 
correlational relationships can be of substantial value, especially in 
automated systems designed to act as decision aids for crew-executed 
functions. Partially predictive contextual information is also valuable since 
it may well form a substantially stronger predictor if paired with other 
partially predictive contextual information. 

• In identifying context-specific information sources, the designer must not 
only appraise the relative utility of the information as an input source for 
the automation, but must also endeavor to ascertain the information's 
veracity, accuracy, and reliability. Such information sources should also 
be evaluated in terms of possible negative consequences of their 
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employment. These concerns should include crew complacency, skilled 
degradation, and over-dependence, especially as they may relate to cases in 
which such information sources (and subsequent automated activities) are 
disrupted or lost altogether. 

System Interface and Operational Considerations 

Several aspects of user interface requirements are relevant to the design of 
automation. In particular, interface issues related to context-specific cuing of 
automated systems must be considered by the designer. A relatively 
comprehensive treatment of these issues is offered by Billings (ref. 4) in his 
NASA technical memorandum, "Human-Centered Aircraft Automation: A 
Concept and Guidelines." Guidelines derived from his treatise — and guidelines 
inspired by it — are presented in this section on controls, displays, and formats. 

Controls, displays, and formats 


• Design automated tasks to be similar to and compatible with pilot task 
performance. 

• Base the decision to announce partial or incipient failures upon pilot needs 
and system functional redundancy. 

• Do not design control automation capable of failing without unambiguous 
and apparent annunciation to the pilot. 


168 



• Consider the consequences of system failures when designing automated 
systems; if these consequences are significant, design the automation to 
assist the crew in dealing with the failure(s). Whenever possible, design 
the automation and its procedures to be understandable in their diagnosis, 
trouble-shooting, and problem solving activities. 

• Design the automation to warn the pilot when the limits of safe operation 
are being approached. 

• Design the automation to either prevent the selection of unsafe operating 
modes or to warn the pilot of their potentially hazardous consequences. 

• Prevent the automation from taking irreversible/irrevocable actions that 
could lead to hazards or mishap. 

• Consider designing the automation to operate under "delimited authority." 
"Delimited authority" implies that the automated system must be designed 
to conduct situation assessment sufficiently early to inform the crew of 
upcoming events, activities, or possible problems — and yet not so early as 
to render such information premature or needlessly speculative (due to 
uncertainties in the ongoing flight situation). 

• Do not impose "hard" limits on the pilots' authority to fly the aircraft 
throughout its operating envelope. 
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• Provide soft limits which alert the pilot that the normal flight envelope has 
been reached. 

• Clearly annunciate or otherwise indicate to the crew that their actions are 
in excess of nominal or typical operating limits, and consider informing 
them precisely as to how long, etc., such limit-exceeding activities can 
safely be continued. 

• Clearly inform the crew as to how to regain nominal operating parameters 
after such limit-exceeding activities have ceased. 

• In general, do not design automated systems to be uninterruptable, either in 
control execution or in processing activities related to such execution. 

• Do not permit easy-access pilot overrides to disengage or nullify systems 
operating along with or alongside the overridden system; any 
circumvention of automation must be done purposefully and with adequate 
knowledge of the consequences of the circumvention. 

• Reduce the workload associated with conducting navigation and guidance 
functions during terminal area operations. 

• Consider developing automation which can adapt to the workload situation 
by providing more or less support as the situation requires. For example. 
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during low workload periods the automation could solicit crew inputs in 
decision making and options evaluation, in high workload, such activities 
could tend to be addressed by the automation. 

• Seek to optimize rather than minimize the level of workload, since low 
workload may also degrade crew performance and awareness. 

• Consider providing meaningful tasks to enhance pilot situation awareness 
and to ensure that the pilot can effectively resume full control of the 
aircraft in the event of a failure or other contingency. 

• Consider requiring pilot consent when it is reasonable to do so as a means 
of maintaining pilot involvement during largely automated operations. 

• Design automated systems to communicate the consequences of inputs, 
preselects, etc., on aircraft operation, especially those likely to result in 
errors and out of tolerance conditions not easily detected by casual human 
observation. 

• Increase the error resistance of automated systems and their associated 
displays by designing clear, simple display formats and by providing 
unambiguous responses to commands. 

• Perform safety hazard analyses of display and control use to identify 
instances where errors may be committed. 
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• Consider designing automation to incorporate the highest possible degree 
of error tolerance by proscribing either potentially hazardous commands 
or by providing the pilot with unambiguous warning of the hazardous 
consequences associated with the implementation of such commands. 

• When preparing to design or modify an automated system, review accident 
and incident data on a frequent basis in order to identify and correct human 
and machine related design deficiencies. 

• Design automation to be flexible enough to accommodate the full range of 
pilot abilities which can be expected to be employed during all phases of 
aircraft operation. 

• Design automation to provide pilots with control and management options 
appropriate to phase of flight environment, and other situation-specific 
contexts. Consider having the automation judiciously assist in determining 
what not to provide also. 

• Present information to the pilot in a form that will maintain or enhance 
situation awareness. 

• Determine the information needs of pilots that do not vary from situation 
to situation, and ensure that this data is available for presentation to pilots 
in a form which is useful for all flight situations. 
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• Determine the specific information needs of each flight situation, and 
evaluate the utility (and consequences) of presenting this data to the pilots 
only when needed. Ensure that the presentation is in a form which 
optimally supports the specific task. 

• Do not provide flight critical information to pilots unless its level of 
validity has been ascertained. 

• Provide some indication to pilots when questionable data is being presented 
to them. 

• Provide pilots with critical information concerning the status of both the 
automation itself as well as the components controlled by that automation. 

• Design automated systems to assist pilots in dealing with the situation of 
automation failure, especially in the context of very reliable systems. Have 
prepared for presentation, information on the consequences of such 
failures, and on a ready means of executing crew/automation compensatory 
actions. 

• Consider providing warnings to the pilots when their actions are expected 
to have potentially negative consequences. 
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• Pilots must be able to accurately predict and understand the automation's 
actions and processes. 

• Design systems, where ever possible, to prevent hazardous interactions 
from occurring, and where prevention is not practical or feasible, to 
minimize the effect of their occurrence. 

• Pilots should be provided with the information necessary to improve their 
awareness of potentially serious situations, and to improve their trust in the 
automated systems. The designer should endeavor to not make this 
presentation of information (e.g., trend data) degrade overall situation 
awareness or increase workload. 

• When warnings occur which are not time-critical, pilots will attempt to 
evaluate the validity of such warnings. When of use to them, means should 
be provided for the crew to conduct these evaluations quickly and 
accurately. 

• Warnings and cautions must be unambiguous. When common signals are 
used to denote more than one condition, there must be a clear indication of 
the specified condition responsible for the alert. For example, accompany 
summary signals, such as a master caution and master warning, with a clear 
indication of the specific condition responsible for activation of the alarm. 
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• Consider allowing the automation to take the first corrective action during 
emergency conditions and then informing the crew of the situation so that 
they can intervene as required. 

• Minimize false or nuisance warnings in order to reduce pilot workload and 
increase their confidence in the warning systems. 

• Provide trend information to the pilots before parameters reach levels 
requiring immediate pilot action, in order to alert them to the existence of 
potentially serious situations. 

• Provide means for the pilots to quickly and easily evaluate the validity of 
all warnings. 

• Present all warnings and alerts to the pilots clearly and unambiguously. 

• When designing information declutter schemes, consider limiting the 
information presented to the pilots to that which is needed to maintain 
situation awareness, and to accomplish the tasks required in the current 
flight situation. The automated system should manage the display of 
information for subsequent portions of the mission such that the crew can 
always have strategic look-ahead access. 

• Consider providing pilots with the capability to selectively declutter their 
displays based on their assessment of what is needed in each flight situation. 
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In such declutter choices, the automation should still alert the crew to any 
vital information. 

• Declutter displays by displaying only that information which the pilot 
routinely needs to perform the current task, but provide the capability to 
rapidly access additional information if the need arise. 

• Ensure crew awareness of updating of all data bases and system status 
relevant to mission completion parameters. 

• Interpret information requirements with particular emphasis on type of 
integration prerequisites, information timing, transfer rates, etc. 

• Provide a positive high level indication of the automation status of each 
subsystem. 

• Provide information on the status of all controlled components and 
functions associated with each automated subsystem in the event of an 
automation failure. 

• Develop "graceful" degradation schemes for all automated systems that 
assist the crew in a broad range of failure conditions. 

• Consider locating the most important information in the center of the 
display. 
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• Consider reinforcing visual information with auditory or tactile 
information where high visual workload exists. 

• Ensure that there is no interference between voice alerts or messages that 
might reduce their effectiveness. 

• Consider back-driving functionally coupled control systems (e.g., stick and 
throttle) to increase situation awareness during automatic modes of 
operation. 

• When designing automation that takes the crew through a sequence of 
inspection or evaluative steps (e.g., with electronic checklists) consider 
providing the following features: 

° Prompting of the crew when a checklist needs to be performed. 

° Reminding the crew of items still to be completed. 

° Acknowledging pilot confirmation of actions. 


177 



Information 


• Information requirements must be derived principally from 
mission/functional requirements. These requirements can be strategic 
(e.g., flight planning) or tactical (e.g., the capability to make emergency 
maneuvers) in nature. Information requirements include not only the 
actual content needed (e.g., airspace sector data, fuel bum rate), but also 
requirements regarding access speed, size and number of active and 
background buffers, relational structure and cross-referencing, and 
updating capabilities. Additionally, all relevant aspects of the data base 
should be readily accessible to the crew for inspection, and, in appropriate 
cases, editing. 

• When determining the updating scheme, the designer should consider such 
automation devices as "hot" updating as long as updates are made to all 
relevant data locations and associated computational routines (e.g., mle 
systems). In such cases of automated updating, the consequences of the 
updates should be evaluated by the system and any counterintuitive, unusual 
or otherwise unanticipated changes of significance to the mission should be 
communicated to the crew. In such designs for the updating function, every 
effort should be made to not burden the crew with unnecessary reports. 
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Human aspects of " intelligent " processing 


• When any form of artificially "intelligent" processing is employed, the 
system must be able to inform the crew about the level of veracity, 
accuracy, and reliability of the processing, given the data, etc., it is 
considering. Confidence levels for decisions, etc., and possible 
consequences of erroneous conclusions of the system's processing must be 
apparent to the crew. 

• When any form of artificially "intelligent" processing is employed, the 
system's design (and the associated training curriculum) should assist crew 
members in forming and maintaining a conceptually accurate mental model 
of all significant aspects of the system's processing. This knowledge of the 
automated system's processing should include awareness of the system's 
strengths, weaknesses, characteristic solutions, etc. 

• When any form of artificially "intelligent" processing is employed, the 
system's design should be such that, for relevant cases, the crew can readily 
determine 'where' the automated system is in a given processing routine 
(e.g., a decision-making routine). Similarly, the crew should be able to 
readily determine subsequent steps in the processing of that routine. The 
designer must determine (from requirements) if and when the crew 
interface should be able to interrupt or edit an automated system’s 
"intelligent" processing. In such cases, the automated system must be able 
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to inform the crew members about the effects of their intercession(s) with 
the processing routine. 

Reasoning , judgement , and decision making — In the design of automated 
systems employing artificial "intelligence," the designer needs to be aware of 
human cognitive strategies and biases, and needs to capitalize on, and/or 
compensate for, these characteristics of human information processing. Human 
reasoning employs strategies and biases in both syllogistic and conditional 
reasoning (i.e., logically deterministic), and in information-incomplete situations. 
A number of these human processing characteristics are relevant to the design of 
automated systems. 

Processing characteristics in syllogistic and conditional reasoning. In 
situations in which problem-solving and decision-making can be solved by logical 
syllogism or by conditional ("if-then") reasoning - that is, by deterministic 
means — humans often exhibit processing strategies and biases that deviate from 
the strict logical appraisal of premises and conclusions. These processing 
characteristics are particularly likely to be employed in time-critical and high 
workload situations, and when the number or complexity of decision factors, or 
potential solutions, is great. The designer is cautioned to keep the following 
processing characteristics in mind whenever developing decision-making and, in 
particular, decision-aiding systems, involving syllogistic or conditional reasoning. 

• Research shows that people sometimes misinterpret or fail to fully consider 
the logical premises involved in a decision-making task. For example, 
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instead of considering all possible meanings of a premise, people will 
interpret the premise as having only one meaning. Similarly, people will 
sometimes consider only a subset of the possible combinations of logical 
premises (based on simplicity or on preferences). In these cases, people 
will reason from such limited interpretations of the premises, thereby 
drawing potentially erroneous conclusions. 

• There is substantial evidence that, in logical reasoning, people will fail to 
accurately consider the consequences of negative information about 
premises. For example, if a given premise is false (thereby logically 
rendering false the conclusion to the syllogism or condition), people will 
sometimes persist in accepting the conclusion as valid. Similarly, people 
tend not to consider counterexamples (to a logical argument) in evaluating 
the veracity of a conclusion (i.e., in deciding whether a given conclusion 
could be contradicted). Moreover, there tends to be a cognitive processing 
bias against seeking any negative (disconfirming) evidence when 
conducting logical reasoning. 

• Research indicates that people sometimes evaluate the veracity of logical 
conclusions on the basis of their beliefs instead of on the logical grounds 
supporting or refuting those conclusions. In particular, people have a 
stronger tendency to accept a believable but invalid conclusion than to 
accept an unbelievable yet valid conclusion. 
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• Empirical evidence suggests that a person in a situation of syllogistic or 
conditional reasoning, will tend to generate a conclusion consistent with the 
logical problem's premises, accept it as valid, and cease considering other 
possible conclusions. This "confirmation" bias may, in part, explain why 
people tend to have difficulty seeking and considering disconfirming 
evidence (see preceding guidelines for discussion). 

Processing characteristics in reasoning under uncertainty . In real- 
world situations, typical problem-solving or decision-making involves reasoning 
in the context of incomplete, degraded, or misleading information. The 
empirical study of such "reasoning under uncertainty" has revealed a number of 
cognitive strategies and biases characteristically employed by humans. The 
designer is advised to keep the following in mind when designing automated 
decision-aiding routines, etc.: 

• Research shows that, when people attempt to estimate probabilities of 
alternative outcomes, they sometimes base these subjective probability 
estimates on how frequently they have encountered this type of outcome, 
and not on its probability. Consider the following example: Hypothetical 
final approach A was a possible outcome in five approaches and was shown 
to be selected in four of those approaches, and final approach C was 
possible in twenty approaches and was shown to be selected in ten of those. 
In such cases, pilots would tend to predict that approach C is more likely to 
occur in a future clearance than is approach A (even though the probability 
of A's occurrence, .8, is substantially higher than C’s, .5). 
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• Research indicates that people's judgements of probabilities of occurrence 
are often influenced by how readily examples of such occurrences come to 
mind. This "availability" heuristic suggests that subjective probability 
estimates can be heavily biased by particular personal experience and by 
memory. 

• In assessing the degree of agreement between decision accuracy and 
decision confidence, it has been shown that people tend to be over- 
confident in cases of relatively high (but not perfect) decision accuracy. 
There is some evidence suggesting that this tendency to exhibit more 
confidence than the accuracy of the decision warrants is due to people's 
incomplete analyses of the decisions being made. 

• When estimating the probability that two independent events (e.g., that 
accidently leaving your front door unlocked would occur on the same day 
that a burglar checks all the doors in the neighborhood), research has 
shown that people tend to substantially over-estimate the probability that 
both events will occur. It is believed that such inaccuracies in subjective 
probability estimation arise from people's tendency to ignore, or not fully 
consider, the base-rate probabilities connected with each of the events. 
Instead, people tend to believe some connection or correlation must exist 
between the events since they co-occurred, thereby (erroneously) 
increasing their estimates of the conjoint event's likelihood. 
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• Empirical research reveals that people will greatly over-estimate the 
likelihood that information obtained in a small number of random 
observations will be representative of a more general pattern or trend. 

• Research shows that, due to memory limitations and processing biases, 
people do not accurately estimate the degree of relatedness between (i.e., 
the correlation) events. Nevertheless, when underlying correlations 
between events are strong, peoples' estimates of relatedness (and therefore, 
predictability) are largely in accord with actual correlations. 

In contrast to this general tendency, it is sometimes the case that people will 
judge a significant relationship to exist between events when, objectively, 
there is no correlational evidence of one. This phenomenon of "illusory 
correlation" is believed to reflect people's tendency to make subjective 
probability estimates of relatedness (in the absence of actual correlational 
evidence) on the basis of implicit theories or beliefs — in effect, people find 
patterns where they want to. It is significant to note that people's beliefs in 
such illusory correlations are difficult to change, even being resistant to 
direct contradictory evidence. 

• Research has shown that, in real-world situations, instead of following 
idealized or optimal decision-making strategies, people prefer to follow 
strategies that yield clear choices, that involve little or no probability 
estimating or computation, and that are readily understood and defended. 
For example, instead of weighing all merits and shortcomings of a 
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decision's alternatives, people will sometimes evaluate only the relative 
merits of the alternatives, or only the relative shortcomings in their 
decisions. In another commonly employed strategy, people choose from 
among decision alternatives by first ranking important features of the 
alternatives, and then eliminating alternatives that don't possess the highest 
ranked feature, then that don't possess the next highest ranked feature, etc., 
until only one alternative remains. 

• Empirical studies have demonstrated that when people engage in real-world 
decision-making activities, they attempt to take into account the costs 
involved in making those decisions. People consider the options lost by 
deciding (therefore sometimes delaying or avoiding the decision), the time 
involved in evaluating alternatives, the number and complexity of the 
alternatives (and their relative merit), and the extent of differences (i.e., 
dissimilarity) between the alternatives. When uncertainty is high, or when 
the potential consequences of an erroneous decision are serious, people will 
sometimes hedge their decisions (e.g., selecting a non-optimal alternative 
that allows options to remain available), or will knowingly take overly 
conservative, but safe, choices. 

Tailored apprising of aircraft systems status, and of consequences of 
current situation — 

• To the maximum extent possible, aircraft system status information, etc., 
should always be available to the crew upon request. And all standard 
caution and alert information should be clearly and unambiguously 
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annunciated to the crew in accord with established and validated 
priority/criticality schemes. Such schemes should be able to accommodate 
any relevant context-specific information which might improve their 
utilization. In no case, however, should context-specific augmentation of 
such schemes be able to result in a dangerous, misleading, or otherwise 
unhelpful modification. 

• In cases where it has been determined that context-sensitive automated 
routines would enhance the capability of a status and alerting system, 
certain design principles should be adhered to. First, all standard status, 
caution, and alerting capabilities must not be impeded in any way; 
therefore, all automated assistance must be limited to advisory functions. 
Within this role, the automated component of a status and alerting system 
should evaluate the status of the aircraft in the context of the aircraft’s 
current flight situation. This examination should attempt to evaluate the 
current and future status of involved systems when such status is not 
readily determinable by direct sensor readings, equipment tolerance bands, 
etc., nor by algorithmic system inspection routines. Instead, this evaluation 
should attempt to use available system status data sources, knowledge of the 
flight situation, and diagnostic routines designed to predict status in cases of 
incomplete or inaccurate data. In addition to providing the best possible 
diagnoses, such probabilistic analyses should clearly and concisely inform 
the crew about the confidence level of the diagnoses, relevant alternative 
possibilities, and significant consequences (positive and negative) of 
accepting or rejecting the diagnoses. The designer should consider that the 
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automated system may be required to estimate near-term and long range 
trends in aircraft system functioning, including potential for eventual 
partial or complete malfunction. Such appraisals should also include 
predictions regarding collateral effects on interrelated systems. 

Extent and type of crew awareness and involvement in automated 

processes 

• In general, the automated system should minimize human involvement in 
tasks that interrupt or otherwise impede the ability to remain aware of the 
current aircraft situation and its occupied airspace, or that lessen the extent 
to which the human can anticipate and speculate about significant upcoming 
events. This being said, there are some obvious difficulties in heeding this 
advice. First, many of the tasks implicated above also produce involvement 
in, and awareness of, important flight-related functions - minimizing crew 
participation in such cases could simply improve awareness in one area at 
the cost of eliminating it in another. Second, determining that a given task 
or function actively reduces awareness (and, for that matter, that a given 
automation routine improves awareness), is not always straightforward 
since actual empirical measurement of situation awareness is, at best, 
equivocal. For these and other reasons, recommending guidelines for level 
of awareness, etc., perhaps just acts to obscure the goal of the designer — to 
develop a system that exploits human capabilities, compensates for human 
weaknesses, and robustly satisfies the mission's requirements. In sum, 
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extent and type of crew involvement should be determined by design 
efforts sensitive to human-centered principles. 

Factors Related to the Automated System's Functional Architecture 

While the design and implementation of an actual functional architecture is 
principally the responsibility of software and hardware developers, the designer 
can and should substantially influence the direction and scope of such activities 
since the system's eventual capabilities often pivot on how a design concept is 
implemented. To this end, the designer should understand the technologies and 
techniques involved, and should have a reasonably informed appreciation for the 
kinds of functional requirements, etc., that will drive software and hardware 
engineers to make the choices they do. Some factors relevant to these concerns 
are now discussed. 

Types of situation-adaptive mechanism used to cue automated routines 

Parasuraman, Bahri, Deaton, Morrison, and Barnes (ref. 15) identify three 
classes of "adaptive" mechanisms to be considered in the design and 
implementation of context-sensitive automation: Mechanisms that empirically 
assess pilot state and performance; mechanisms that model or theoretically 
represent (and thus predict) pilot state, performance, or intentions; and 
mechanisms that use mission requirements, events, etc., and situation-specific 
information. These classes of mechanism are now considered with respect to 
their potential utility. 
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Empirical assessment of pilot state and performance — Empirical 
evaluation of pilot state typically considers mental and/or physical workload, 
situation awareness, vigilance, and fatigue. Evaluation of pilot performance 
generally focuses on aspects of task execution (duration, accuracy, and nature of 
performance errors), and the effects of this execution on other tasks (done in 
parallel or subsequent to the task under evaluation). In empirical assessments of 
state or performance, it is typically assumed that such data will, of course, 
constitute crucial information for the triggering of automated routines - 
however, such obtained data does not, in and of itself, cause the automated 
routines to be initiated. Instead some rule system, etc., taking this empirical data 
as inputs, must still specify when and how a given automated routine will be 
employed. Even so, the designer's critical appraisal of the quality and timeliness 
of such data is essential since the adaptive decision scheme (e.g., rule system) is 
largely dependent on it. 

• With regard to assessment of pilot state, the designer must decide whether 
physiological (e.g., heart rate), and/or subjective (e.g., pilot workload 
ratings) measures will be employed. In either case, the designer must 
endeavor to use the most technically and statistically reliable, accurate, and 
non-intmsive measures available. In addition, serious consideration should 
be given to practical concerns such as: How much and what kind of data is 
required, signal processing complexity (in the case of certain physiological 
measures), and the relative discriminability or diagnosticity that these 
measures are likely to provide (e.g., to date, physiological indices of 
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mental activity are only able to distinguish relatively general conditions of 
cognitive processing. Their functional utility with regard to, say, inferring 
specific intent, is virtually nil.) 

• With regard to assessing workload, the designer should determine what 
aspects of workload would be potentially useful as cuing mechanisms (e.g., 
visual versus auditory workload; mental workload associated with decision 
making versus with remembering), and which of these might be reliably 
obtainable. 

• When employing empirical assessment, the system must be able to interpret 
the functional significance of distinguishable differences in pilot state or 
performance; differences that are discemable but not interpre table are of 
little use as cuing mechanisms. 

Models of pilot state , performance , or intention — Parasuraman, Bahri, 
Deaton, Morrison, and Bames (ref. 15) identify several types of modelling 
approaches to representing (and predicting) pilot-related variables: Models that 
can represent aspects of pilot workload (e.g., involving task-related changes in 
workload), models of cognitive processing (e.g., "executive" processing models), 
and models of pilot performance and intention (e.g., queuing theory models, and 
intent inferencing systems). In some contrast to the empirical mechanisms 
discussed previously, modelling approaches have often integrally combined the 
modelling of pilot states, etc., with some set of strategies, rules, etc., for directly 
triggering an adaptive automated routine. As such, the designer's evaluation of 
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modelling approaches must consider both how well a given model predicts the 
relevant pilot variable (e.g., workload), and how effectively the model's 
strategies, rules, etc., perform their adaptive function for initiating automated 
assistance. 

• When considering the use of a model for predicting a pilot variable, the 
designer should, whenever possible, obtain statistically rigorous validity 
and reliability indices successfully comparing the model's predictions with 
empirically obtained indicants of the pilot variable of interest. 
Additionally, the designer should verify that the model's input 
requirements, etc., can be satisfied for the situation (e.g., mission segment) 
to be modelled. 

• When considering the use of a model for predicting a pilot variable, the 
designer should verify that the model appears to be more efficient than (or 
otherwise preferable to) representing the pilot variable empirically. 

• When considering the use of a model to predict a pilot variable, the 
designer should compare the modelling approach to rival approaches, 
evaluating it for strength of predictability, scope of applicability, number 
and value of beneficial features, ease of implementation, and risks 
associated with software/hardware technologies and programming 
techniques employed. 
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Mission events and situation-specific cues — Parasuraman, Bahri, 
Deaton, Morrison, and Barnes (ref. 15) refer to the use of mission events for 
prompting automated sequences as employing "critical event" logics. These 
authors adopt Barnes and Grossman's (1985) typology of such logics: 

Emergency log ic, in which a control process is executed without pilot 
intervention initiation or intervention... 

Executive log ic, in which the subprocesses leading up to the decision to 
activate the process are automatically invoked, with the final decision 
requiring the pilot's input... 

Automated display logic, in which all non-critical display findings are 
automated to prepare for a particular event, so that the pilot can 
concentrate on the most important tasks, (p. 18) 

Several mission and situation-specific events can be employed in such critical- 
event logics, among them being: 

- Mission phases, segments, etc. 

- Current and planned aircraft position and performance data 

- Crew inputs (whether correct, erroneous, absent, or delayed) 

- ATC inputs 

- Current and anticipated environmental conditions 

- Time requirements 
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- Emergencies, malfunctions, and other abnormal conditions 

• When considering the use of a critical-event scheme as an adaptive 
mechanism, the designer should continually evaluate how that critical-event 
logic satisfies mission functions. Moreover, since critical-event logics are 
particularly dependent on mission events, this ongoing evaluation should 
consider the critical-event logic's potential for success in future 
applications (in which mission functions are likely to change), and in near- 
term applications involving retrofit issues, operations in mixed fleets, and 
interactions with variable ATC capabilities. 

• When considering the use of a critical-event logic as an adaptive 
mechanism, the designer must understand the logic's effects on collateral 
and subsequent events in the mission to the maximum extent possible. This 
understanding must be both tactical and strategic, and must consider 
unlikely and critical situations as well as expected nominal performance. 
And the designer is reminded that, since the rule systems, etc., governing 
critical-event schemes will typically incorporate some 
deterministic/conditional logic (e.g., if-then sequences), evaluating the 
effects of the critical event scheme necessarily entails evaluating all 
outcome possibilities of these rules (even seemingly innocuous, trivial, or 
null outcomes). 

• When considering the use of a critical event logic as an adaptive 
mechanism, the designer must have a clear idea of what failures and 
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malfunctions in the critical-event scheme will look like. The designer must 
not only have a means for identifying such anomalies, but must ensure that 
the automated system can, where possible, 'trap' for them (i.e., by 
programming, etc., preempt their occurrence), annunciate relevant aspects 
of their etiologies and effects when they do occur, and provide means for 
compensating for these occurrences. 

• When considering the use of a critical-event logic as an adaptive 

mechanism, the designer should keep in mind Parasuraman, Bahri, Deaton, 
Morrison, and Barnes' (ref. 15) criticism of such schemes: 

The problem with these [critical-event logic] systems is that they 
are relatively unsophisticated and are unresponsive to actual operator 
workload or performance, it is even possible that their rule bases 
have unforeseen, interactive consequences in a complex environment. 

(p. 18) 

As such, the designer should consider following a design philosophy that 
is biased toward relatively low autonomy for the automated system, 
since, in critical-event applications, the crew and ATC typically 
constitute vital elements of the system's overall "intelligence" and 
decision-making capability. 
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Programming and computational techniques used to control 
automated systems 

Several classes of programming and computation can be employed in 
implementing automated systems, including the following: 

- Standard algorithmic and related mle-based techniques 

- "General case plus variant" modelling (e.g., frame-based 

programming) 

- "Judgement" and "Reasoning" programming designed to work in 

circumstances involving uncertain or poorly understood parameters 

- Probabilistic and estimating techniques, including "neural network 

systems" 

• When deciding to use a computational or programming technique, the 
designer should consider the technique's ability to help satisfy the 
software requirements previously derived from the automated system's 
design requirements (which, in turn, should follow from the mission's 
and the human operator’s requirements). In many cases, it may turn out 
that various requirements are better addressed by particular techniques 
and, thus, different components of the automated system may be 
supported by different programming approaches. A number of these 
software requirements are considered below. 
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When deciding on a programming approach, the designer should 
have determined operationally representative estimates of timing 
requirements for data search, loading, etc., for central processing 
(e.g., decision-making), and for interaction with the system 
interface. 

° When deciding on a programming approach, the designer should 
endeavor to ascertain the system's required computational capacity in 
terms of amount and complexity of computing. This might be 
achieved by estimating peak calculation rates, number and 
complexity of parallel computations potentially required, etc. 

° When deciding on a programming approach, the designer should 
endeavor to determine the levels of certainty, accuracy, etc., to be 
required by the automated system’s (operational) functioning. 

° Where applicable, when deciding on a programming approach, the 
designer should ascertain the extent of uncertainty, ambiguity, etc., 
inherent in the functional phenomenon being modelled or estimated 
since certain computational techniques are specialized for such 
situations. 

° When deciding on a programming approach, the designer should 
endeavor to employ the computational techniques least likely to 
produce erroneous, inconclusive, obsolete, or misleading outputs, 
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and yet still fulfill the design requirements for the automated system. 
Such selections of low risk programming techniques must, of course, 
be weighed against the potential losses in computational 
sophistication and power that might have been provided by more 
high risk techniques. 

° When deciding on a programming approach, the designer should 
evaluate the ease, flexibility, and power of the approach to 
implement operator interact and system integration functions. 

• In cases where a requirement has been established for the automated 
system to produce a solution (e.g., a decision), etc., that resembles or is 
consistent with the corresponding human solution, the software should 
mimic the human cognitive processes, strategies, and preferences 
leading to that solution only when : 

- It is generally believed that some advantage exists (e.g., better 
solution, faster decision) for the solution obtained by human 
cognitive processing, and/or 

- There appears to be some collateral benefit afforded the operator 
(e.g., improved confidence in the solution, improved situation 
awareness) by him or her recognizing and agreeing with the 
system's processing. 
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With regard to this consideration, the designer should endeavor to 
determine the extent to which the automated routine must be able to 
report partial solutions (e.g., a best estimate when only half through the 
required processing) or other interim processing (e.g., at some point in 
a particular decision-making process, the system has narrowed the 
number of possible solutions to X alternatives...). This determination 
should be based on operational and human information processing 
requirements, not on simple technological capability or practical 
feasibility. 

• For cases in which an Expert System approach is to be implemented, the 
designer should ensure that the knowledge base from the subject-matter 
expert include demonstrated expert competence, in terms of actions, 
safe-guarding procedures, etc., as well as declarative knowledge and 
opinions about how experts think and act. 

• For cases in which an Expert System approach is to be implemented, the 
designer should ensure that the number and variety of experts consulted, 
and the contexts in which these experts are observed, be adequate to 
develop a representative model of the "expert." 
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Integration of the Automated System with Other Systems 

When an automated system is implemented as a component of an aircraft's 
onboard avionics suite, it necessarily interacts with other components to 
achieve functional utility. These interactions can range from simple data 
transfers to complex command and control relationships, whatever the nature 
of these interactions, their effective execution is essential to advanced aircraft 
operations. As such, design decisions affecting the functional integration of 
such component systems must be carefully and thoroughly considered by the 
designer. To this end, the following guidelines are offered. 

Integration among onboard systems for enhanced performance 

• System integration schemes should be designed such that crew members 
are not the sole means of data input, data transfer, etc., between 
functionally related systems (e.g., Data Link and the Right Management 
System). In general, direct system-to-system data transfer (with 
appropriate user interface, etc., safeguards in place) should always be 
possible. 

• Relevant timing, accuracy, speed, and format requirements for 
retrieval, transfer, processing, and updating should be compatible 
between functionally related systems. 
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• Where advantageous and safe, all related data bases should update 
adequately to fully support mission, user, and system design 
requirements. Moreover, such updating should, in general, be "hot" - 
that is, data common to several data bases should be updated in all data 
bases automatically whenever it is updated in one. This characteristic 
extends to also include the hot updating of the products of any 
computations, etc., generated from the relevant data. 

• In cases where related systems utilize extensive and/or critical amounts 
of the same data, the designer should consider having the systems share 
one data base or at least integrate the (partially) redundant data bases 
for use as mutual backups. 

Integration among onboard systems for improved safety 

• In all cases of shared data (or shared products of that data), reliable and 
accurate safeguards regarding error detection, and error propagation 
must be continuously operational. 

• The design of any automated system should endeavor to adhere to all 
recognized avionics development standards regarding that system's 
integration with other systems, including any standards concerning 
processing or computational redundancies, etc. 
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The designer should consider providing some degree of functional 
redundancy among related systems to enable the component systems to 
perform cross-checking and backup functions. Such capabilities might 
also be employed in compensatory routines responding to degraded 
performance, malfunctions, etc. Whatever the use of such functionally 
redundant capabilities, the source (i.e., the system) responsible for any 
calculations, estimates, etc., must always be readily apparent to the 
crew. 

Integration schemes should be designed such that they maximize the 
probability that vital functions of the aircraft's systems will continue to 
perform (at some level of adequacy) when related component systems 
partially or completely fail. 

Integration schemes should be designed such that, in the event of partial 
failures, malfunctions, etc., every functional level of degraded operation 
retains essential flight and navigation functions (even if this is at the 
expense of other capabilities). That is, system integration, even in 
degraded modes, follows a function priori torization that preserves 
essential functions at all costs. 



Integration with ground-based systems 


• The design of the automated system should consider critical features of 
ground-based systems with which it must communicate. These features 
can include: Data transmission formats, protocols, and baud rates; 
transmission and other physical characteristics (e.g., periodicity of 
message transmission over Mode S data link); and possible sources of 
error, malfunction, etc. 

• The design of the automated system should be such that it does not 
depend solely on ground-based data for essential functions. 

• The design of the automated system should be such that it does not 
overburden, impede, or otherwise lessen the overall utility of the 
ground-based system. 
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